[Bug target/38824] [4.4 Regression] performance regression of sse code from 4.2/4.3
--- Comment #23 from bonzini at gnu dot org 2009-02-11 08:01 --- Subject: Re: [4.4 Regression] performance regression of sse code from 4.2/4.3 [xg...@shgcc-9 38824]$ time ./gcc-42.out real0m1.991s [xg...@shgcc-9 38824]$ time ./gcc-44.out real0m1.880s [xg...@shgcc-9 38824]$ time ./gcc-44p.out real0m1.690s Even though you don't observe the reporter's slowdown from 4.2/4.3 to unpatched 4.4, I guess this makes a good case for the patch. Ok for trunk? Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38824
[Bug target/38824] [4.4 Regression] performance regression of sse code from 4.2/4.3
--- Comment #24 from ubizjak at gmail dot com 2009-02-11 08:14 --- (In reply to comment #23) Even though you don't observe the reporter's slowdown from 4.2/4.3 to unpatched 4.4, I guess this makes a good case for the patch. Ok for trunk? OK with a ChangeLog ;) BTW: Please watch benchmarks testers [1] for a couple of days... [1] http://gcc.gnu.org/benchmarks/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38824
[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation
--- Comment #16 from ubizjak at gmail dot com 2009-02-11 08:24 --- (In reply to comment #13) This test case is from Mark Heffernan. When compiling with -O2 -fno-omit-frame-pointer with gcc 4.3, it shows a red zone violation in the epilogue: movl-160(%rbp), %eax popq%r15 leave ret This does not show redzone violation, but following does: popq%rbx popq%r12 popq%r13 popq%r14 movl-160(%rbp), %eax popq%r15 leave ret Anyway, I have a patch. -- ubizjak at gmail dot com changed: What|Removed |Added Status|REOPENED|ASSIGNED Last reconfirmed|2009-02-08 21:00:58 |2009-02-11 08:24:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118
[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation
--- Comment #17 from ubizjak at gmail dot com 2009-02-11 08:32 --- Created an attachment (id=17280) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17280action=view) Patch This patch inserts _memory_ blockages at the end of function prologue and at the beginning of function epilogue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118
[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign
--- Comment #11 from ubizjak at gmail dot com 2009-02-11 08:42 --- (In reply to comment #9) Created an attachment (id=17279) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17279action=view) [edit] A patch to add a new -malign-double= option HJ, there were lots of problems with similar approach, see this revert: 2008-03-23 Uros Bizjak ubiz...@gmail.com Revert: 2008-03-05 H.J. Lu hongjiu...@intel.com * config/i386/i386-modes.def: Use 4 byte alignment on DI for 32bit host. 2008-03-19 Uros Bizjak ubiz...@gmail.com PR target/35496 * stor-layout.c (update_alignment_for_field): Set minimum alignment of the underlying type of a MS bitfield layout to the natural alignment of the type. 2008-03-22 Uros Bizjak ubiz...@gmail.com * config/i386/i386.c (assign_386_stack_local): Align DImode slots to their natural alignment to avoid store forwarding stalls. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
[Bug target/38824] [4.4 Regression] performance regression of sse code from 4.2/4.3
--- Comment #25 from bonzini at gnu dot org 2009-02-11 08:57 --- patch committed (the changelog was in gcc-patches :-). -- bonzini at gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38824
[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation
--- Comment #19 from uros at gcc dot gnu dot org 2009-02-11 11:43 --- Subject: Bug 39118 Author: uros Date: Wed Feb 11 11:43:24 2009 New Revision: 144100 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144100 Log: PR target/39118 * config/i386/i386.md (UNSPEC_MEMORY_BLOCKAGE): New constant. (memory_blockage): New expander. (*memory_blockage): New insn pattern. * config/i386/i386.c (ix86_expand_prologue): Use memory_blockage instead of general blockage at the end of function prologue when frame pointer is used to access red zone area. Do not emit blockage when profiling, it is emitted in generic code. (ix86_expand_epilogue): Emit memory_blockage at the beginning of function epilogue when frame pointer is used to access red zone area. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118
[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation
--- Comment #20 from uros at gcc dot gnu dot org 2009-02-11 11:53 --- Subject: Bug 39118 Author: uros Date: Wed Feb 11 11:53:47 2009 New Revision: 144101 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144101 Log: PR target/39118 * config/i386/i386.md (UNSPEC_MEMORY_BLOCKAGE): New constant. (memory_blockage): New expander. (*memory_blockage): New insn pattern. * config/i386/i386.c (ix86_expand_prologue): Use memory_blockage instead of general blockage at the end of function prologue when frame pointer is used to access red zone area. Do not emit blockage when profiling, it is emitted in generic code. (ix86_expand_epilogue): Emit memory_blockage at the beginning of function epilogue when frame pointer is used to access red zone area. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/i386/i386.c branches/gcc-4_3-branch/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118
[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation
--- Comment #21 from ubizjak at gmail dot com 2009-02-11 11:55 --- Fixed again. -- ubizjak at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2009- |patches/2009- |02/msg00372.html|02/msg00512.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118
[Bug middle-end/22448] ICE on dereferencing a label in an asm statement
--- Comment #4 from trick at icculus dot org 2009-02-11 13:38 ---
This also happens when dereferencing void pointers (this is invalid code
though, but I get the same error with the code in the first post):
void foo (void *p)
{
asm( :: g (*p));
}
$ gcc -c foo.c
foo.c: In function foo:
foo.c:3: warning: dereferencing void * pointer
foo.c:3: internal compiler error: in gimplify_expr, at gimplify.c:6288
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
$ gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr --enable-shared
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --enable-threads=posix
--mandir=/usr/share/man --infodir=/usr/share/info --enable-__cxa_atexit
--disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu
--disable-libstdcxx-pch --with-tune=generic
Thread model: posix
gcc version 4.3.3 (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22448
[Bug inline-asm/39078] Registers in on clober list are cloberred when compiled with optimization (x86_64) ?
--- Comment #8 from valery_reznic at yahoo dot com 2009-02-11 14:26 --- (In reply to comment #7) (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 I read it. Still I don't get the point. In the inline assembler I MYSELF put arguments in the places where MY (by the way, written in assembler) function expect to get them. I need nothing from gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39078
[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign
--- Comment #12 from hjl dot tools at gmail dot com 2009-02-11 14:39 --- (In reply to comment #11) (In reply to comment #9) Created an attachment (id=17279) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17279action=view) [edit] A patch to add a new -malign-double= option HJ, there were lots of problems with similar approach, see this revert: Another reason for the new option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation
--- Comment #22 from ian at airs dot com 2009-02-11 14:49 --- Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39118
[Bug fortran/35476] Accepts invalid: USE/host association of generics with same specifics
-- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35476
[Bug target/39146] Unnecessary stack alignment
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-11 15:15 ---
This is caused by assign_parms in function.c:
/* Estimate stack alignment from parameter alignment. */
if (SUPPORTS_STACK_ALIGNMENT)
{
unsigned int align = FUNCTION_ARG_BOUNDARY (data.promoted_mode,
data.passed_type);
if (TYPE_ALIGN (data.nominal_type) align)
align = TYPE_ALIGN (data.passed_type);
if (crtl-stack_alignment_estimated align)
{
gcc_assert (!crtl-stack_realign_processed);
crtl-stack_alignment_estimated = align;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[Bug inline-asm/39078] Registers in on clober list are cloberred when compiled with optimization (x86_64) ?
--- Comment #9 from ubizjak at gmail dot com 2009-02-11 15:32 --- (In reply to comment #8) In the inline assembler I MYSELF put arguments in the places where MY (by the way, written in assembler) function expect to get them. Then you actually don't need a compiler... ;) I need nothing from gcc. True. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39078
[Bug fortran/35476] Accepts invalid: USE/host association of generics with same specifics
--- Comment #6 from burnus at gcc dot gnu dot org 2009-02-11 15:36 --- See: http://www.j3-fortran.org/doc/meeting/187/09-006A.txt and there NUMBER: F03/0116. One now only needs to carefully read the text to understand the interpretation. Additionally, it needs to pass some more review (J3 and then WG5). Current STATUS: J3 consideration in progress -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35476
[Bug target/39148] -Os increase code size when stack is aligned
--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-11 17:11 --- If you mean setting ACCUMULATE_OUTGOING_ARGS to true, I bet that could help very small functions that need dynamic realignment, but certainly for larger functions !ACCUMULATE_OUTGOING_ARGS results in smaller code, even if realignment is done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148
[Bug target/39148] -Os increase code size when stack is aligned
--- Comment #4 from hjl dot tools at gmail dot com 2009-02-11 17:16 --- (In reply to comment #3) If you mean setting ACCUMULATE_OUTGOING_ARGS to true, I bet that could help Oops. Yes, I meant setting ACCUMULATE_OUTGOING_ARGS to true when stack alignment is needed. very small functions that need dynamic realignment, but certainly for larger functions !ACCUMULATE_OUTGOING_ARGS results in smaller code, even if realignment is done. Joey and Xuepeng are running http://www.inf.u-szeged.hu/csibe/ to see how ACCUMULATE_OUTGOING_ARGS affects code size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148
[Bug c++/38228] [4.2/4.3/4.4 regression] ICE with invalid use of bound member function
--- Comment #5 from paolo dot carlini at oracle dot com 2009-02-11 17:52 --- Paolo, should this be assigned to you? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38228
[Bug bootstrap/37739] [4.4 Regression] bootstrap broken with core gcc gcc-4.2.x
--- Comment #12 from lucier at math dot purdue dot edu 2009-02-11 18:13 --- I just got the same error with 140 12:54 ../../gcc-4.3.3/configure --prefix=/pkgs/gcc-4.3.3 --enable-languages=c 141 12:54 make -j 4 bootstrap build.log trying to build gcc-4.3.3 with [luc...@descartes gcc-4.3.3]$ gcc -v Using built-in specs. Target: ppc64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --enable-secureplt --with-long-double-128 --build=ppc64-redhat-linux --target=ppc64-redhat-linux --with-cpu=default32 Thread model: posix gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) So, if it was fixed on mainline, it wasn't fixed on the branch. Should I just reopen this against 4.3.3, or should I file a new bug report for 4.3.3 and refer back to this one. -- lucier at math dot purdue dot edu changed: What|Removed |Added CC||lucier at math dot purdue ||dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
[Bug c/33466] mixed-case suffix for decimal float constants
--- Comment #4 from janis at gcc dot gnu dot org 2009-02-11 18:27 --- N1169 says that the suffix for a fixed-point literal constant is case insensitive, which to me means that uhk can be uhK/uHk/uHK/Uhk/UhK/UHk as well as UHK. It's easier to implement that way, but if it's really supposed to be a single case then I'd rather fix that now. I asked a question about this, and about GCC's use of ll or LL as a length indicator in fixed-point suffixes, in http://gcc.gnu.org/ml/gcc/2009-02/msg00191.html but there are people copied on this PR who probably don't follow that mailing list. If you're familiar with the fixed-point TR, please let me know your interpretation of this, or whether there's a later draft of the TR than N1169. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33466
[Bug c++/38228] [4.2/4.3/4.4 regression] ICE with invalid use of bound member function
--- Comment #6 from bonzini at gnu dot org 2009-02-11 18:59 --- hm if i didn't look at it so far, i guess no. :-( but if i have time i will look at it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38228
[Bug target/38306] [4.4 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
--- Comment #12 from bonzini at gnu dot org 2009-02-11 19:00 --- /* For -O2 and beyond, turn off -fschedule-insns by default. It tends to make the problem with not enough registers even worse. */ As risky as this may be (for performance, not correctness), what about changing if (level 1) to if (level == 2)? And what about enabling it on x86-64? -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
[Bug target/39152] New: [4.4 regression] 416.gamess in SPEC CPU 2006 failed
On Linux/ia32, revision 144101 gave: gfortran -m32 -c -o mccas.fppized.o-O2 -ffast-math -mfpmath=sse -mssse3 -ffixed-form mccas.fppized.f mccas.fppized.f: In function 'cashes': mccas.fppized.f:1745: error: unrecognizable insn: (insn 364 296 365 5 mccas.fppized.f:1712 (set (reg/v:SI 4 si [orig:93 ii ] [93]) (mem/s:SI (plus:SI (ashift:SI (reg:SI 3 bx) (const_int 2 [0x2])) (const:SI (plus:SI (symbol_ref:SI (ijpair_) var_decl 0x2b5442f74f00 ijpair) (const_int -4 [0xfffc] [2 ijpair.ia S4 A32])) -1 (nil)) mccas.fppized.f:1745: internal compiler error: in extract_insn, at recog.c:2038 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. specmake: *** [mccas.fppized.o] Error 1 Revision 144092 is OK. -- Summary: [4.4 regression] 416.gamess in SPEC CPU 2006 failed Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39152
[Bug bootstrap/33100] [4.3/4.4 regression] on bootstrap getting section .eh_frame: bad cie version 0: offset 0x0
--- Comment #36 from bugzilla-gcc at thewrittenword dot com 2009-02-11 19:03 --- (In reply to comment #26) We have filed case #65952072 with Sun to get this backported to Solaris 10. Do you have any news about this? Sun just released patch 139574-03 for SPARC and 139575-03 for x86. We've built gcc-4.2.4 with the x86 patch and it resolved the issue for us. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33100
[Bug target/38056] Missed tail calls on ia64
--- Comment #2 from sje at cup dot hp dot com 2009-02-11 19:04 --- This behaviour changed with the patch to fix PR 10907 and I believe that GCC is correct in not doing the tail call optimization. The optimization is not done because ia64_function_ok_for_sibcall returns false and it returns false because bar is defined in a different object file. That object could be in a shared library and could change the GP. Thus GCC needs to save and restore the GP when making calls to another object file and that inhibits the tail call optimization. If bar were defined in the same file GCC could and does do the tail call optimization. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38056
[Bug target/38306] [4.4 Regression] 15% slowdown w.r.t. 4.3 of computational kernel on some architectures
--- Comment #13 from jv244 at cam dot ac dot uk 2009-02-11 19:25 --- (In reply to comment #12) /* For -O2 and beyond, turn off -fschedule-insns by default. It tends to make the problem with not enough registers even worse. */ As risky as this may be (for performance, not correctness), what about changing if (level 1) to if (level == 2)? And what about enabling it on x86-64? But even on x86-64 this seems to lead to ICEs (see PR38403). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
[Bug c++/39153] New: virtual default dtor not defined
Compiling:
struct _Impl_base
{
_Impl_base() = default;
virtual ~_Impl_base() = default;
};
templatetypename _Tp
class _Impl : public _Impl_base
{ };
int main()
{
_Implint i;
return 0;
}
Gives:
gcc version 4.4.0 20090208 (experimental) (GCC)
%COMP.sh -g -O0 -std=c++0x -fno-inline vague_vs_default.cc
vague_vs_default.cc:4: warning: inline function virtual
_Impl_base::~_Impl_base() used but never defined
vague_vs_default.cc:4: warning: inline function virtual
_Impl_base::~_Impl_base() used but never defined
Which seems strange, as the base destructor is defined as default.
Also, the vauge linkage/vtable documentation bits here
http://gcc.gnu.org/onlinedocs/gcc-3.0.2/gcc_6.html#SEC118
may need to be updated or expanded to take into account defaulted destructors
vs. key method vtable emission.
--
Summary: virtual default dtor not defined
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39153
[Bug middle-end/39154] New: Miscompilation of VLAs in nested parallel regions
The following testcase segfaults at runtime or ICEs (with checking compiler):
extern void abort (void);
int n = 20;
int
main ()
{
int a[n], b[n][n];
#pragma omp parallel for
for (int i = 0; i n; i++)
{
a[i] = i + 1;
#pragma omp parallel for
for (int j = 0; j n; j++)
b[i][j] = a[i];
}
for (int i = 0; i n; i++)
{
for (int j = 0; j n; j++)
if (b[i][j] != i + 1)
abort ();
if (a[i] != i + 1)
abort ();
}
#pragma omp parallel for shared (n, a, b)
for (int i = 0; i n; i++)
{
a[i] = i + 3;
#pragma omp parallel for
for (int j = 0; j n; j++)
b[i][j] = a[i];
}
for (int i = 0; i n; i++)
{
for (int j = 0; j n; j++)
if (b[i][j] != i + 3)
abort ();
if (a[i] != i + 3)
abort ();
}
#pragma omp parallel for
for (int i = 0; i n; i++)
{
a[i] = i + 5;
#pragma omp parallel for shared (n, a, b)
for (int j = 0; j n; j++)
b[i][j] = a[i];
}
for (int i = 0; i n; i++)
{
for (int j = 0; j n; j++)
if (b[i][j] != i + 5)
abort ();
if (a[i] != i + 5)
abort ();
}
#pragma omp parallel for shared (n, a, b)
for (int i = 0; i n; i++)
{
a[i] = i + 7;
#pragma omp parallel for shared (n, a, b)
for (int j = 0; j n; j++)
b[i][j] = a[i];
}
for (int i = 0; i n; i++)
{
for (int j = 0; j n; j++)
if (b[i][j] != i + 7)
abort ();
if (a[i] != i + 7)
abort ();
}
return 0;
}
--
Summary: Miscompilation of VLAs in nested parallel regions
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code, ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: jakub at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39154
[Bug target/39152] [4.4 regression] Revision 144098 breaks 416.gamess in SPEC CPU 2006
--- Comment #1 from hjl dot tools at gmail dot com 2009-02-11 20:24 --- Revision 144098: http://gcc.gnu.org/ml/gcc-cvs/2009-02/msg00264.html is the cause. Joey, Xuepeng, can you find a small testcase? -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||Joey dot ye at intel dot ||com, xuepeng dot guo at ||intel dot com, bonzini at ||gnu dot org Summary|[4.4 regression] 416.gamess |[4.4 regression] Revision |in SPEC CPU 2006 failed |144098 breaks 416.gamess in ||SPEC CPU 2006 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39152
[Bug target/39152] [4.4 regression] Revision 144098 breaks 416.gamess in SPEC CPU 2006
--- Comment #2 from bonzini at gnu dot org 2009-02-11 20:48 --- Why is this unrecognizable?!? ebx can be an index as well as the base. Anyway, easily fixed. Will post a patch tomorrow. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-11 20:48:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39152
[Bug bootstrap/39151] If you build and install 'ppl' (and not 'cloog') then files will still link with 'ppl'.
--- Comment #1 from rob1weld at aol dot com 2009-02-11 20:54 --- A workaround is to ./configure using --without-ppl which will cause ppllibs to create an empty variable in the Makefiles. The output from the initial configuring will look the same, but this Bug will be avoided. I'm going to drop this to Minor since this might be an uncommon situation and there are two workarounds (and no fix, yet). The second workaround is to uninstall 'ppl' _or_ install 'cloog' which is not likely near as good a solution as the first workaround (in _these_ particular circumstances). Rob -- rob1weld at aol dot com changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39151
[Bug bootstrap/39150] Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-11 20:56 --- How is this major, this is an enhancement to the build system. i386-solaris is a multi arch target so it includes the x86_64 solaris target also. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150
[Bug target/39152] [4.4 regression] Revision 144098 breaks 416.gamess in SPEC CPU 2006
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-11 20:59 --- A testcase: [...@gnu-27 Docs]$ cat /tmp/x.f SUBROUTINE CASHES(E,HESS,FC,FA,NORB,NPR) IMPLICIT DOUBLE PRECISION (A-H,O-Z) PARAMETER (MXAO=2047) DIMENSION HESS(NPR),E(NORB,*),FC(*),FA(*) COMMON /IJPAIR/ IA(MXAO) COMMON /MCPAR / NFZC,NCORBS,NCI,NORBS,NORBX,NUM K=0 DO 200 IU = 1,NORB - NCORBS I = IU + NCORBS II=IA(I)+I DO 100 J = 1,NCORBS IF (I.GT.NORBS) THEN HESS(K)=FC(II) + FA(II) - E(J,J) ELSE HESS(K)=FA(II) - E(I,I) - E(J,J) + FC(JJ) + FA(JJ) END IF 100CONTINUE 200 CONTINUE RETURN END [...@gnu-27 Docs]$ /export/gnu/import/rrs/144098/usr/bin/gfortran -m32 -S -O2 -msse2 -mfpmath=sse -ffast-math -ffixed-form /tmp/x.f /tmp/x.f: In function cashes: /tmp/x.f:19: error: unrecognizable insn: (insn 178 144 179 4 /tmp/x.f:10 (set (reg/v:SI 4 si [orig:73 ii ] [73]) (mem/s:SI (plus:SI (ashift:SI (reg:SI 3 bx) (const_int 2 [0x2])) (const:SI (plus:SI (symbol_ref:SI (ijpair_) var_decl 0x2b73b1ef0aa0 ijpair) (const_int -4 [0xfffc] [3 ijpair.ia S4 A32])) -1 (nil)) /tmp/x.f:19: internal compiler error: in extract_insn, at recog.c:2038 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [...@gnu-27 Docs]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39152
[Bug c++/39155] New: Internal compiler error on (invalid) explicit template instantiation of template function
The following code causes an internal compiler error when compiled with g++
without options:
namespace N{templateclass T void foo();}
using namespace N;
templateclass T void foo(){}
template void fooint();
Compiler info:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.0.1/configure
--prefix=/usr/local/compilers/gcc-4.0.1-x86_64-x86_64 --enable-languages=c,c++
--enable-bootstrap
Thread model: posix
gcc version 4.0.1
The code compiles with a useful diagnostic (and no internal error) when
compiled with this newer version of gcc:
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)
--
Summary: Internal compiler error on (invalid) explicit template
instantiation of template function
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cas43 at cs dot stanford dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39155
[Bug c++/39155] Internal compiler error on (invalid) explicit template instantiation of template function
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-11 21:08 --- You reported this against 4.0.1 and 4.0.x and 4.1.x are no longer being supported (meaning no more 4.0.x or 4.1.x release). Since it has been fixed in 4.1.2, I am closing this as fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 Version|4.1.2 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39155
[Bug c++/39156] New: Internal compiler error on (invalid) use of undefined type in template function
This line of code causes an internal compiler when compiled with g++ without
options:
class B;templateclass T void foo(B x) {x(0);}
Compiler:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.0.1/configure
--prefix=/usr/local/compilers/gcc-4.0.1-x86_64-x86_64 --enable-languages=c,c++
--enable-bootstrap
Thread model: posix
gcc version 4.0.1
Compiling with this newer version yields a meaningful diagnostic instead of an
internal error:
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-14)
--
Summary: Internal compiler error on (invalid) use of undefined
type in template function
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: cas43 at cs dot stanford dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39156
[Bug c++/39156] Internal compiler error on (invalid) use of undefined type in template function
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-11 21:12 --- You reported this against 4.0.1 and 4.0.x and 4.1.x are no longer being supported (meaning no more 4.0.x or 4.1.x release). Since it has been fixed in 4.1.2, I am closing this as fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 Version|4.1.2 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39156
[Bug target/39152] [4.4 regression] Revision 144098 breaks 416.gamess in SPEC CPU 2006
--- Comment #4 from bonzini at gnu dot org 2009-02-11 21:20 --- The problem is that inside mems we use MULT not ASHIFT. Can you please test this? Thanks! --- config/i386/i386.md (revision 144098) +++ config/i386/i386.md (working copy) @@ -20722,7 +20722,7 @@ (parallel [(set (match_dup 0) (match_op_dup 3 [(match_dup 0) (match_dup 1)])) (clobber (reg:CC FLAGS_REG))])] - operands[4] = simplify_replace_rtx (operands[2], operands[0], operands[1]);) + operands[4] = replace_rtx (operands[2], operands[0], operands[1]);) (define_peephole2 [(set (match_operand 0 register_operand ) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39152
[Bug target/39152] [4.4 regression] Revision 144098 breaks 416.gamess in SPEC CPU 2006
--- Comment #5 from bonzini at gnu dot org 2009-02-11 21:20 --- There was wrapping, all you have to do is remove simplify_. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39152
[Bug c++/28274] [4.0/4.1/4.2 Regression] Redeclaration with extra default argument doesn't work
--- Comment #9 from jason at gcc dot gnu dot org 2009-02-11 21:28 ---
This is still broken inside extern C:
extern C {
void foo (int i, int j = 6);
void foo (int i = 4, int j);
}
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28274
[Bug c++/28274] [4.2/4.3/4.4 Regression] Redeclaration with extra default argument doesn't work
--- Comment #10 from jason at gcc dot gnu dot org 2009-02-11 21:31 --- The extern C testcase passed under the 3.2 compiler; marking as regression. -- jason at gcc dot gnu dot org changed: What|Removed |Added Known to work|3.3.6 3.4.0 3.4.5 4.0.2 |3.3.6 3.4.0 3.4.5 4.0.2 |4.0.4 4.1.2 4.2.0 |4.0.4 4.1.2 Priority|P1 |P2 Summary|[4.0/4.1/4.2 Regression]|[4.2/4.3/4.4 Regression] |Redeclaration with extra|Redeclaration with extra |default argument doesn't|default argument doesn't |work|work http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28274
[Bug c++/34691] [4.2/4.3/4.4 Regression] Default argument checking not performed after overload resolution with C linkage
--- Comment #8 from jason at gcc dot gnu dot org 2009-02-11 21:31 --- I've reopened PR 28274 with the PR in comment #2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34691
[Bug target/39152] [4.4 regression] Revision 144098 breaks 416.gamess in SPEC CPU 2006
--- Comment #6 from dominiq at lps dot ens dot fr 2009-02-11 21:41 --- With the patch in comment #4 the test in comment #3 compiles without ICE on i686-apple-darwin9 (it gave an ICE before the patch). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39152
[Bug middle-end/39157] New: Code that compiles fine in 1GB of memory with 4.1.2 requires 20GB in 4.2.* and higher
With this compiler [luc...@descartes gambit]$ gcc -v Using built-in specs. Target: powerpc64-unknown-linux-gnu Configured with: ../../gcc-4.3.3/configure --prefix=/pkgs/gcc-4.3.3 --enable-languages=c --with-cpu=default64 Thread model: posix gcc version 4.3.3 (GCC) with the file compiler.i found here: http://www.math.purdue.edu/~lucier/bugzilla/8/ attempting to compile with these options: gcc -m64 -mcpu=970 -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -rdynamic -shared can't compile in 8GB of RAM. With this compiler: euler-77% /pkgs/gcc-4.2.3/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../../gcc-4.2.3/configure --prefix=/pkgs/gcc-4.2.3 --enable-checking=release --with-gmp=/pkgs/gmp-4.2.2 --with-mpfr=/pkgs/gmp-4.2.2 Thread model: posix gcc version 4.2.3 and these options: gcc -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -rdynamic -shared it can't compiler in 20GB of RAM. (That machine has only 16GB of RAM, so I killed the compile when it hit 20GB of physical+virtual memory.) It compiles just fine in about 1GB of RAM with euler-76% gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/pkgs/gcc-4.1.2 Thread model: posix gcc version 4.1.2 compiler.i is the output from the Gambit Scheme-C compiler; the source scheme program is from a standard benchmark suite for Scheme compilers. So I found this by trying to change the code generator for Gambit and running the benchmark suite on x86_64. I don't know how this can be fixed. Basically, the entire middle-end infrastructure since 4.1.* is telling people like me with computer-generated code like this to just go away (to put it very politely). On Mac OS X 10.5.*, Apple bundles their version of 4.0.1, which compiles this just fine; on Red Hat 5.2, they bundle their version of 4.1.2 (I think, my RH5.2 box is down at the moment), which compiles this just fine; but on Ubuntu 8.10 or Fedora 10 you can't compile this because they bundle newer compilers. (I guess I'll see if I can install 4.1.* on both of these.) As a stopgap measure, perhaps someone can tell me what optimization level to use. As you can see, I use -O1 and a few others (mainly -fschedule-insns2). gcc 4.1.* and earlier compiled something like this just fine, but -O1 must mean something different now. -- Summary: Code that compiles fine in 1GB of memory with 4.1.2 requires 20GB in 4.2.* and higher Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157
[Bug c++/39153] virtual default dtor not defined
-- 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 | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-11 21:56:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39153
[Bug middle-end/39154] Miscompilation of VLAs in nested parallel regions
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-11 21:58 --- Subject: Bug 39154 Author: jakub Date: Wed Feb 11 21:57:52 2009 New Revision: 144111 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144111 Log: PR middle-end/39154 * gimplify.c (omp_notice_variable): If adding GOVD_SEEN bit to variable length decl's flags, add it also to its pointer replacement variable. * testsuite/libgomp.c/pr39154.c: New test. Added: trunk/libgomp/testsuite/libgomp.c/pr39154.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39154
[Bug middle-end/39154] Miscompilation of VLAs in nested parallel regions
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-11 22:02 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-11 22:02:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39154
[Bug c++/36954] Wrong warning with -Wlogical-op
-- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org BugsThisDependsOn||16302 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-11 22:08:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36954
[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-02-11 22:11 --- Is there a reason why this is a P1? I don't see why this should be a P1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
[Bug c++/39158] New: virtual default dtor not defined
Compiling:
struct _Impl_base
{
_Impl_base() = default;
virtual ~_Impl_base() = default;
};
templatetypename _Tp
class _Impl : public _Impl_base
{ };
int main()
{
_Implint i;
return 0;
}
Gives:
gcc version 4.4.0 20090208 (experimental) (GCC)
%COMP.sh -g -O0 -std=c++0x -fno-inline vague_vs_default.cc
vague_vs_default.cc:4: warning: inline function virtual
_Impl_base::~_Impl_base() used but never defined
vague_vs_default.cc:4: warning: inline function virtual
_Impl_base::~_Impl_base() used but never defined
Which seems strange, as the base destructor is defined as default.
Also, the vauge linkage/vtable documentation bits here
http://gcc.gnu.org/onlinedocs/gcc-3.0.2/gcc_6.html#SEC118
may need to be updated or expanded to take into account defaulted destructors
vs. key method vtable emission.
--
Summary: virtual default dtor not defined
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39158
[Bug target/36513] -Wlogical-op warns about strchr
--- Comment #2 from manu at gcc dot gnu dot org 2009-02-11 22:13 --- We need a reproducible preprocessed testcase. See http://gcc.gnu.org/bugs.html#detailed -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36513
[Bug c++/39153] virtual default dtor not defined
--- Comment #1 from bkoz at gcc dot gnu dot org 2009-02-11 22:13 --- *** Bug 39158 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39153
[Bug c++/39158] virtual default dtor not defined
--- Comment #1 from bkoz at gcc dot gnu dot org 2009-02-11 22:13 --- Whoops, wrong state in browser *** This bug has been marked as a duplicate of 39153 *** -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39158
[Bug c++/30111] Value-initialization of POD base class doesn't initialize members
--- Comment #9 from jason at gcc dot gnu dot org 2009-02-11 22:38 --- Subject: Bug 30111 Author: jason Date: Wed Feb 11 22:38:37 2009 New Revision: 144112 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144112 Log: PR c++/30111 * init.c (build_value_init_noctor): Split out from... (build_value_init): ...here. (expand_aggr_init_1): Handle value-initialization. * cp-tree.h: Add declaration. * class.c (type_has_user_provided_constructor): Handle non-class arguments. Added: trunk/gcc/testsuite/g++.dg/init/value7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30111
[Bug c++/30111] Value-initialization of POD base class doesn't initialize members
--- Comment #10 from jason at gcc dot gnu dot org 2009-02-11 22:50 --- Fixed for 4.4. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30111
[Bug c/32061] (Wlogical-op) wording of warning of constant logicials need improvement
--- Comment #3 from manu at gcc dot gnu dot org 2009-02-11 23:04 --- Confirmed. I have a patch for this for 4.5. The new wording will say: warning: logical 'or' applied to non-boolean constant. Are you satisfied with this? BTW, why no warning for this? resp == 0 0 Naturally, all the above constants will hide behind some macros which could indicate a real error, hence the value of the warning. Warning for (x 0) or (x 1) would produce hundreds of false positives. We shouldn't warn about your testcase either. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-11 23:04:41 date|| Summary|wording of warning of |(Wlogical-op) wording of |constant logicials need |warning of constant |improvement |logicials need improvement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32061
[Bug c++/39054] [4.3 regression] ICE with invalid pseudo-dtor in template
--- Comment #4 from jason at gcc dot gnu dot org 2009-02-11 23:04 --- Fixed for 4.3 as well. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39054
[Bug target/38056] Missed tail calls on ia64
--- Comment #3 from jsworley at qwest dot net 2009-02-11 23:41 --- Accepting Steve Ellcey's analysis, it would seem that the tail call *should* be recognized when -mconstant-gp is specified; however, it isn't. -- jsworley at qwest dot net changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38056
[Bug c++/39159] New: unhelpful attribute warning on matching declaration after definition
gcc 4.3 issues a warning for the declaration of struct A below despite the
attribute on the declaration being consistent with that on the definition and
thus benign. While the warning is valuable in cases where the attributes
between the declaration and the definition do not match, it is not useful in
benign cases such as the one below. In these cases the warning makes applying
the attribute difficult in existing C++ libraries that rely heavily but not
completely on forward declarations and that also already make use of the Visual
C++ __declspec(dllexport) feature or the Sun C++ __global or __protected
specifiers, neither of which warns about such benign cases.
$ cat t.C g++ -c t.C
struct __attribute__ ((visibility (default))) A { };
struct __attribute__ ((visibility (default))) A;
t.C:2: warning: type attributes ignored after type is already defined
--
Summary: unhelpful attribute warning on matching declaration
after definition
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39159
[Bug target/39146] Unnecessary stack alignment
--- Comment #4 from hjl dot tools at gmail dot com 2009-02-11 23:59 --- The dynamic stack alignment may not be easy to optimize out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[Bug other/28322] GCC new warnings and compatibility
--- Comment #24 from manu at gcc dot gnu dot org 2009-02-12 00:25 --- Is there anything that remains to be done here? -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28322
[Bug target/39148] -Os increase code size when stack is aligned
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-12 00:44 --- I tried -maccumulate-outgoing-args on 2.6 kernel: textdata bss dec hex filename 5136786 600084 1003520 6740390 66d9a6 vmlinux 5086759 600084 1003520 6690363 66163b /tmp/vmlinux.old It does increase binary size. Should we consider to turn on ACCUMULATE_OUTGOING_ARGS when stack is aligned? If ACCUMULATE_OUTGOING_ARGS is off, ECX will be used for stack alignment and it may lead to code size increase due to register spill since ia32 has very few registers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148
[Bug ada/39160] New: Assert_Failure in sinfo.adb
Note that the test code is not semantically correct. Correct code compiles just fine. For me, the bug manifests in both 4.3.2 and the 4.4-20090206 snapshot. Configure options: --disable-multilib --enable-languages=c,ada System type: $ uname -ro 2.6.27.12-170.2.5.fc10.x86_64 GNU/Linux Output: $ gcc -c bug.adb +===GNAT BUG DETECTED==+ | 4.4.0 20090206 (experimental) (x86_64-unknown-linux-gnu) Assert_Failure sinfo.adb:1987| | Error detected at bug.adb:17:26 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ -- Summary: Assert_Failure in sinfo.adb Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wilsons at start dot ca GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39160
[Bug ada/39160] Assert_Failure in sinfo.adb
--- Comment #1 from wilsons at start dot ca 2009-02-12 00:56 --- Created an attachment (id=17282) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17282action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39160
[Bug target/39152] [4.4 regression] Revision 144098 breaks 416.gamess in SPEC CPU 2006
--- Comment #7 from hjl dot tools at gmail dot com 2009-02-12 01:38 --- (In reply to comment #4) The problem is that inside mems we use MULT not ASHIFT. Can you please test this? Thanks! --- config/i386/i386.md (revision 144098) +++ config/i386/i386.md (working copy) @@ -20722,7 +20722,7 @@ (parallel [(set (match_dup 0) (match_op_dup 3 [(match_dup 0) (match_dup 1)])) (clobber (reg:CC FLAGS_REG))])] - operands[4] = simplify_replace_rtx (operands[2], operands[0], operands[1]);) + operands[4] = replace_rtx (operands[2], operands[0], operands[1]);) (define_peephole2 [(set (match_operand 0 register_operand ) I verified that this fixed 416.gamess. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39152
[Bug target/39146] Unnecessary stack alignment
--- Comment #5 from Joey dot ye at intel dot com 2009-02-12 01:45 --- Stack realign is finalized by stack_realign = (incoming_stack_boundary (current_function_is_leaf ? crtl-max_used_stack_slot_alignment : crtl-stack_alignment_needed)); since bar is leaf function, it checks max_used_stack_slot_alignment. According to it's definition, max_used_stack_slot_alignment is /* The largest alignment of slot allocated on the stack. */. Parameter x isn't allocated on local stack, so max_used_stack_slot_alignment shouldn't be set to 256 bits. In locate_and_pad_parm, if (crtl-max_used_stack_slot_alignment crtl-stack_alignment_needed) crtl-max_used_stack_slot_alignment = crtl-stack_alignment_needed; sets max_used_stack_slot_alignment to 256 bits, which seems shouldn't happen all the time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[Bug target/39146] Unnecessary stack alignment
--- Comment #6 from hjl dot tools at gmail dot com 2009-02-12 01:58 --- locate_and_pad_parm in function.c has /* Remember if the outgoing parameter requires extra alignment on the calling function side. */ if (crtl-stack_alignment_needed boundary) crtl-stack_alignment_needed = boundary; if (crtl-max_used_stack_slot_alignment crtl-stack_alignment_needed) crtl-max_used_stack_slot_alignment = crtl-stack_alignment_needed; if (crtl-preferred_stack_boundary boundary) crtl-preferred_stack_boundary = boundary; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[Bug c++/39153] virtual default dtor not defined
--- Comment #2 from jason at gcc dot gnu dot org 2009-02-12 02:01 --- Subject: Bug 39153 Author: jason Date: Thu Feb 12 02:01:07 2009 New Revision: 144119 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144119 Log: PR c++/39153 * decl2.c (cp_write_global_declarations): Check DECL_DEFAULTED_FN, not DECL_ARTIFICIAL. Added: trunk/gcc/testsuite/g++.dg/cpp0x/defaulted9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39153
[Bug libgcj/39161] New: gcc 4.4.0 20090210 - The 'copy-vmresources.sh' script can't find the 'mkinstalldirs' script.
I am building gcc 4.4.0 20090210 [trunk revision 144083] on OpenSolaris 2009.06 . The 'copy-vmresources.sh' script can't find the 'mkinstalldirs' script. # isainfo -k amd64 # uname -a SunOS opensolaris 5.11 snv_106 i86pc i386 i86pc # gcc/xgcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --build=i386-pc-solaris2.11 --target=i386-pc-solaris2.11 --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-multilib --enable-decimal-float --with-long-double-128 --with-included-gettext --enable-stage1-checking --enable-checking=release --with-tune=k8 --with-cpu=k8 --with-arch=k8 --with-gnu-as --with-as=/usr/local/bin/as --without-gnu-ld --with-ld=/usr/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local --without-ppl Thread model: posix gcc version 4.4.0 20090210 (experimental) [trunk revision 144083] (GCC) # gmake ... (long time) mkdir ../gnu/java/locale ../../../../../gcc_trunk/libjava/classpath/scripts/generate-locale-list.sh ../gnu/java/locale/LocaleData.java true top_builddir=.. top_srcdir=../../../../../gcc_trunk/libjava/classpath /bin/sh ./gen-classlist.sh standard Adding java source files from srcdir '../../../../../gcc_trunk/libjava/classpath'. Adding java source files from VM directory /usr/share/src/gcc_trunk/libjava Adding java source files from VM directory /usr/share/src/gcc_build/i386-pc-solaris2.11/libjava Adding generated files in builddir '..'. touch compile-classes mkdir gnu mkdir gnu/javax mkdir gnu/javax/security ... mkdir META-INF mkdir META-INF/services ./copy-vmresources.sh[34]: mkinstalldirs: not found [No such file or directory] ./copy-vmresources.sh[34]: /usr/share/src/gcc_build/i386-pc-solaris2.11/libjava/classpath/lib/./classpath/resource/java/util/logging/: not found [No such file or directory] ./copy-vmresources.sh[34]: mkinstalldirs: not found [No such file or directory] ./copy-vmresources.sh[34]: /usr/share/src/gcc_build/i386-pc-solaris2.11/libjava/classpath/lib/./classpath/resource/java/util/: not found [No such file or directory] ./copy-vmresources.sh[34]: mkinstalldirs: not found [No such file or directory] ./copy-vmresources.sh[34]: /usr/share/src/gcc_build/i386-pc-solaris2.11/libjava/classpath/lib/./classpath/resource/java/util/: not found [No such file or directory] ./copy-vmresources.sh[34]: mkinstalldirs: not found [No such file or directory] ./copy-vmresources.sh[34]: /usr/share/src/gcc_build/i386-pc-solaris2.11/libjava/classpath/lib/./classpath/resource/java/text/: not found [No such file or directory] (many, many more) ... # find ../gcc_build/ -name copy-vmresources.sh i386-pc-solaris2.11/amd64/libjava/classpath/lib/copy-vmresources.sh i386-pc-solaris2.11/libjava/classpath/lib/copy-vmresources.sh # find ../gcc_trunk/ -name mkinstalldirs ../gcc_trunk/libjava/classpath/mkinstalldirs ../gcc_trunk/mkinstalldirs Those errors do _not_ cause the build to fail. The library (and gcc) will continue to build and the Testsuite Results are 'reasonably good'. Rob -- Summary: gcc 4.4.0 20090210 - The 'copy-vmresources.sh' script can't find the 'mkinstalldirs' script. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i386-pc-solaris2.11 GCC host triplet: i386-pc-solaris2.11 GCC target triplet: i386-pc-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39161
[Bug target/39162] New: Gcc doesn't warn __m256 when -mavx isn't used
bash-3.2$ cat /tmp/x.i
typedef long long __m256i __attribute__ ((__vector_size__ (32),
__may_alias__));
__m256i
bar (__m256i x)
{
return x;
}
bash-3.2$ gcc -S /tmp/x.i
This is due to type_natural_mode doesn't check 32byte types. If I
add
--- ./i386.c.warn 2009-02-11 06:58:52.0 -0800
+++ ./i386.c2009-02-11 18:03:30.0 -0800
@@ -4729,7 +4729,7 @@ type_natural_mode (const_tree type)
if (TREE_CODE (type) == VECTOR_TYPE !VECTOR_MODE_P (mode))
{
HOST_WIDE_INT size = int_size_in_bytes (type);
- if ((size == 8 || size == 16)
+ if ((size == 8 || size == 16 || size == 32)
/* ??? Generic code allows us to create width 1 vectors. Ignore. */
TYPE_VECTOR_SUBPARTS (type) 1)
{
I got
bash-3.2$ ./xgcc -B./ -O2 /tmp/x.i -S
/tmp/x.i: In function bar:
/tmp/x.i:3: warning: AVX vector argument without AVX enabled changes the ABI
/tmp/x.i:6: internal compiler error: in emit_move_multi_word, at expr.c:3317
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
emit_move_multi_word isn't prepared to deal with it.
--
Summary: Gcc doesn't warn __m256 when -mavx isn't used
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39162
[Bug c++/39153] virtual default dtor not defined
--- Comment #3 from jason at gcc dot gnu dot org 2009-02-12 02:12 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39153
[Bug target/39162] Gcc doesn't warn __m256 when -mavx isn't used
--- Comment #1 from hjl dot tools at gmail dot com 2009-02-12 02:14 --- I think we should make it an error instead. -- 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=39162
[Bug target/39146] Unnecessary stack alignment
--- Comment #7 from Joey dot ye at intel dot com 2009-02-12 02:26 --- Created an attachment (id=17283) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17283action=view) A patch to fix this problem Impact to other test unknown. Test undergoing. HJ, can you also help to verify and test this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[Bug target/39148] -Os increase code size when stack is aligned
--- Comment #6 from Joey dot ye at intel dot com 2009-02-12 02:33 --- (In reply to comment #5) If ACCUMULATE_OUTGOING_ARGS is off, ECX will be used for stack alignment and it may lead to code size increase due to register spill since ia32 has very few registers. The code increase resulted from stack realign are mainly from prologue increase. ECX is only used as hard register in prologue/epilogue and the impact to function body is low. If ACCUMULATE_OUTGOING_ARGS does increase code size, then for big functions, benefit of !ACCUMULATE_OUTGOING_ARGS will offset increase of prologue/epilogue. So simply enable ACCUMULATE_OUTGOING_ARGS for stack realign isn't be the best option for all cases either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148
[Bug target/39146] Unnecessary stack alignment
--- Comment #8 from hjl dot tools at gmail dot com 2009-02-12 02:33 --- (In reply to comment #7) Created an attachment (id=17283) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17283action=view) [edit] A patch to fix this problem Impact to other test unknown. Test undergoing. HJ, can you also help to verify and test this patch? With your patch, I got .globl bar .type bar, @function bar: pushq %rbp movq%rsp, %rbp leave ret We still have push and mov. I guess it may be the best we can do. But please run full 32 and 64bit testsuite with your patch as well as under emx-avx-sim. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[Bug target/39148] -Os increase code size when stack is aligned
--- Comment #7 from hjl dot tools at gmail dot com 2009-02-12 02:37 --- (In reply to comment #6) So simply enable ACCUMULATE_OUTGOING_ARGS for stack realign isn't be the best option for all cases either. OK. I am closing as WONTFIX. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148
[Bug target/39146] Unnecessary stack alignment
--- Comment #9 from Joey dot ye at intel dot com 2009-02-12 02:40 --- (In reply to comment #8) We still have push and mov. I guess it may be the best we can do. I believe so too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[Bug c/33466] mixed-case suffix for decimal float constants
--- Comment #5 from tydeman at tybor dot com 2009-02-12 02:54 --- The latest version of TR 18037 is WG14 document N1275 of 2007/10/01. The suffix really is case insensitive, so 'uhk' has 8 variations. 'll' and 'LL' are not valid suffixes for fixed point constants. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33466
[Bug target/36480] stack-protector causes bad ARM PIC code generated
--- Comment #1 from dougkwan at google dot com 2009-02-12 03:04 ---
I have a test case now. The toolchain is built with gcc trunk, binutils-2.18,
gdb-6.71 and newlib-1.16.0 for target arm-eabi
---
#include stdlib.h
extern int sprintf (char *, const char*, ...);
int
main (void)
{
char buf[10];
sprintf(buf, );
return 0;
}
#
# Test case exits with an error code if compiled with -fstack-protector -fpic
#
sh-3.1$ arm-eabi-gcc -fstack-protector -fpic bug.csh-3.1$ arm-eabi-gdb a.out
GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as --host=i686-unknown-linux-gnu --target=arm-eabi...
(gdb) target sim
Connected to the simulator.
(gdb) load a.out
Loading section .init, size 0x18 vma 0x8000
Loading section .text, size 0x2af8 vma 0x8018
Loading section .fini, size 0x18 vma 0xab10
Loading section .rodata, size 0xd4 vma 0xab28
Loading section .ARM.exidx, size 0x8 vma 0xabfc
Loading section .eh_frame, size 0x4 vma 0xac04
Loading section .init_array, size 0x8 vma 0x12c08
Loading section .fini_array, size 0x4 vma 0x12c10
Loading section .jcr, size 0x4 vma 0x12c14
Loading section .got, size 0x10 vma 0x12c18
Loading section .data, size 0x930 vma 0x12c28
Start address 0x80ac
Transfer rate: 109248 bits in 1 sec.
(gdb) run
Starting program: /usr/local/google/data/dougkwan/arm-elf/test/a.out
Program exited with code 0377.
(gdb) quit
#
# It exits normally with -fstack-protector only
#
sh-3.1$ arm-eabi-gcc -fstack-protector bug.c
sh-3.1$ arm-eabi-gdb a.out
GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as --host=i686-unknown-linux-gnu --target=arm-eabi...
(gdb) target sim
Connected to the simulator.
(gdb) load a.out
Loading section .init, size 0x18 vma 0x8000
Loading section .text, size 0x2adc vma 0x8018
Loading section .fini, size 0x18 vma 0xaaf4
Loading section .rodata, size 0xd4 vma 0xab0c
Loading section .ARM.exidx, size 0x8 vma 0xabe0
Loading section .eh_frame, size 0x4 vma 0xabe8
Loading section .init_array, size 0x8 vma 0x12bec
Loading section .fini_array, size 0x4 vma 0x12bf4
Loading section .jcr, size 0x4 vma 0x12bf8
Loading section .data, size 0x930 vma 0x12c00
Start address 0x80ac
Transfer rate: 108896 bits in 1 sec.
(gdb) run
Starting program: /usr/local/google/data/dougkwan/arm-elf/test/a.out
Program exited normally.
(gdb) quit
#
# It also exits normally if -O2 is given in addition to -fstack-protector
-fpic
#
sh-3.1$ arm-eabi-gcc -fstack-protector -fpic -O2 bug.c
sh-3.1$ arm-eabi-gdb a.out
GNU gdb 6.7.1
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as --host=i686-unknown-linux-gnu --target=arm-eabi...
(gdb) target sim
Connected to the simulator.
(gdb) load a.out
Loading section .init, size 0x18 vma 0x8000
Loading section .text, size 0x2ae0 vma 0x8018
Loading section .fini, size 0x18 vma 0xaaf8
Loading section .rodata, size 0xd4 vma 0xab10
Loading section .ARM.exidx, size 0x8 vma 0xabe4
Loading section .eh_frame, size 0x4 vma 0xabec
Loading section .init_array, size 0x8 vma 0x12bf0
Loading section .fini_array, size 0x4 vma 0x12bf8
Loading section .jcr, size 0x4 vma 0x12bfc
Loading section .got, size 0x10 vma 0x12c00
Loading section .data, size 0x930 vma 0x12c10
Start address 0x80ac
Transfer rate: 109056 bits in 1 sec.
(gdb) run
Starting program: /usr/local/google/data/dougkwan/arm-elf/test/a.out
Program exited normally.
(gdb) quit
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36480
[Bug c++/39163] New: -mstackalign breaks -O2 optimization using g++
This is basically a copy of bug report from
http://www.dribin.org/dave/blog/archives/2006/12/05/missing_third_param/
Using the following sample file saved as test.c:
#include stdio.h
#define NOINLINE __attribute__((noinline))
NOINLINE static void foo1(int i1)
{
printf(foo1: %d\n, i1);
}
NOINLINE static void foo2(int i1, int i2)
{
printf(foo2: %d, %d\n, i1, i2);
}
NOINLINE static void foo3(int i1, int i2, int i3)
{
printf(foo3: %d, %d, %d\n, i1, i2, i3);
}
NOINLINE static void foo4(int i1, int i2, int i3, int i4)
{
printf(foo4: %d, %d, %d, %d\n, i1, i2, i3, i4);
}
NOINLINE static void foo5(int i1, int i2, int i3, int i4, int i5)
{
printf(foo5: %d, %d, %d, %d, %d\n, i1, i2, i3, i4, i5);
}
NOINLINE static void foo6(int i1, int i2, int i3, int i4, int i5, int i6)
{
printf(foo6: %d, %d, %d, %d, %d, %d\n, i1, i2, i3, i4, i5, i6);
}
int main(int argc, char **argv)
{
foo1(1);
foo2(1, 2);
foo3(1, 2, 3);
foo4(1, 2, 3, 4);
foo5(1, 2, 3, 4, 5);
foo6(1, 2, 3, 4, 5, 6);
return 0;
}
produces invalid output (broken 3rd parameter) if compiled using g++ and
-mstackrealign:
/usr/toolchains/gcc433/bin/g++ -Wall -mstackrealign -O2 test.c
./a.out
foo1: 1
foo2: 1, 2
foo3: 1, 2, -1209632279
foo4: 1, 2, 4, 134520820
foo5: 1, 2, 4, 5, -1074446840
foo6: 1, 2, 4, 5, 6, 134514537
However if gcc is used instead of g++, valid output is generated:
/usr/toolchains/gcc433/bin/gcc -mstackrealign -Wall -O2 test.c
./a.out
foo1: 1
foo2: 1, 2
foo3: 1, 2, 3
foo4: 1, 2, 3, 4
foo5: 1, 2, 3, 4, 5
foo6: 1, 2, 3, 4, 5, 6
Analyze of assembly dump revealed that GCC still uses ECX in main() to pass the
parameter. ix86_internal_arg_pointer() in i386.c works fine, and returns same
values for gcc and g++, so the problem is not there.
--
Summary: -mstackalign breaks -O2 optimization using g++
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gyunaev at ulduzsoft dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39163
[Bug c++/39163] -mstackalign breaks -O2 optimization using g++
--- Comment #1 from gyunaev at ulduzsoft dot com 2009-02-12 04:19 --- Created an attachment (id=17284) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17284action=view) test.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39163
[Bug c++/39133] wrong optimization produces output of false warning
--- Comment #3 from corinl at gmx dot de 2009-02-12 07:26 ---
Thanks for the info. Unluckily I just found the bug reported first now for
sure:
Code:
// setuid/setgid only affect the current thread
#define FS_PERMS_SET(_uid, _gid) \
bool check_permissions_local = check_permissions; \
uid_t fs_perms_uid_orig; \
gid_t fs_perms_gid_orig; \
if (check_permissions_local) \
{ \
fs_perms_uid_orig = setfsuid(_uid); \
fs_perms_gid_orig = setfsgid(_gid); \
}
// setuid/setgid only affect the current thread
#define FS_PERMS_RESTORE() \
if (check_permissions_local) \
{ \
setfsuid(fs_perms_uid_orig); \
setfsgid(fs_perms_gid_orig); \
}
#define FOP_ERRNO(R) out-op_errno=((R==0)?0:errno)
...
line 934:
FS_PERMS_SET(in-uid, in-gid);
FOP_ERRNO(statvfs(path, out-stbuf));
FS_PERMS_RESTORE();
...
Error report:
main.cpp:934: Warnung: »fs_perms_gid_orig« könnte in dieser Funktion
uninitialisiert verwendet werden
main.cpp:934: Warnung: »fs_perms_uid_orig« könnte in dieser Funktion
uninitialisiert verwendet werden
This is not true, as at this point the variables are only written to. They are
only ever read (and even later) if they have first been written to.
--
corinl at gmx dot de changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39133
[Bug c++/39133] wrong optimization produces output of false warning
--- Comment #4 from corinl at gmx dot de 2009-02-12 07:37 ---
here's the copy from the precompiled header file (.ii), may be it helps:
(check_permissions_local removed, it was just for test..same error as before)
uid_t fs_perms_uid_orig; gid_t fs_perms_gid_orig; if (check_permissions) {
fs_perms_uid_orig = setfsuid(in-uid); fs_perms_gid_orig = setfsgid(in-gid);
};
out-op_errno=((statvfs(path, out-stbuf)==0)?0:(*__errno_location ()));
if (check_permissions) { setfsuid(fs_perms_uid_orig);
setfsgid(fs_perms_gid_orig); };
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39133
[Bug c++/39164] New: defaulted dtor redefinition not caught
From revision 144119:
struct _Impl_base
{
_Impl_base() = default;
#if 1
~_Impl_base() = default;
#else
~_Impl_base() { }
#endif
};
_Impl_base::~_Impl_base() { }
int main()
{
_Impl_base i;
return 0;
}
compiled:
%COMP.sh -std=c++0x -g -O2 -Wall -Wextra default2.cc
Has no error, when:
default2.cc:12: error: redefinition of �_Impl_base::~_Impl_base()�
default2.cc:8: error: �_Impl_base::~_Impl_base()� previously defined here
Is expected. Code in #else should be equivalent to #if.
--
Summary: defaulted dtor redefinition not caught
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39164
