[Bug fortran/37577] Change internal array descriptor format for better syntax, C interop TR, rank 15
--- Comment #2 from tkoenig at gcc dot gnu dot org 2009-05-08 06:27 --- Subject: Bug 37577 Author: tkoenig Date: Fri May 8 06:27:37 2009 New Revision: 147269 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147269 Log: 2009-05-08 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/37577 * intrinsics/pack_generic.c (pack_internal): Use array access macros for accessing array descriptors. (pack_s_internal): Likewise. * intrinsics/transpose_generic.c (transpose_internal): Remove size argument, calculate from array descriptor. Use array access macros for accessing array descriptors. (transpose): Remove size argument from call. (transpoe_char): Likewise. (transpose_char4): Likewise. * intrinsics/move_alloc.c (move_alloc): Use array access macros for accessing array descriptors. * intrinsics/spread_generic.c (spread_internal): Remove size argument, calculate from array descriptor. Use array access macros for accessing array descriptors. (spread_internal_scalar): Likewise. (spread): Remove size argument from call to spread_internal. (spread_char): Mark argument source_length as unused. Remove size argument from call to spread_internal. (spread_char4): Likewise. (spread_char_scalar): Likewise. (spread_char4_scalar): Likewise. * intrinsics/unpack_generic.c (unpack_internal): Use array access macros for accessing array descriptors. * intrinsics/eoshift2.c (eoshift2): Remove size argument, calculate from array descriptor instead. Use array access macros for accessing array descriptors. (eoshift2_##N): Remove size argument from call to eoshift2. (eoshift2_##N_##char): Likewise. (eoshift2_##N_##char4): Likewise. * intrinsics/reshape_generic.c (reshape_internal): Use array access macross for accessing array descriptors. Modified: branches/fortran-dev/libgfortran/ChangeLog.dev branches/fortran-dev/libgfortran/intrinsics/eoshift2.c branches/fortran-dev/libgfortran/intrinsics/move_alloc.c branches/fortran-dev/libgfortran/intrinsics/pack_generic.c branches/fortran-dev/libgfortran/intrinsics/reshape_generic.c branches/fortran-dev/libgfortran/intrinsics/spread_generic.c branches/fortran-dev/libgfortran/intrinsics/transpose_generic.c branches/fortran-dev/libgfortran/intrinsics/unpack_generic.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37577
[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #78 from bonzini at gnu dot org 2009-05-08 06:51 --- Subject: Bug 33928 Author: bonzini Date: Fri May 8 06:51:12 2009 New Revision: 147270 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147270 Log: 2009-05-08 Paolo Bonzini bonz...@gnu.org PR rtl-optimization/33928 * loop-invariant.c (struct use): Add addr_use_p. (struct def): Add n_addr_uses. (struct invariant): Add cheap_address. (create_new_invariant): Set cheap_address. (record_use): Accept df_ref. Set addr_use_p and update n_addr_uses. (record_uses): Pass df_ref to record_use. (get_inv_cost): Do not add inv-cost to comp_cost for cheap addresses used only as such. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-invariant.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #79 from bonzini at gnu dot org 2009-05-08 07:18 --- I'm cobbling up the DIY dataflow patch and it is all but ugly, actually. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #80 from bonzini at gnu dot org 2009-05-08 07:51 --- Subject: Bug 33928 Author: bonzini Date: Fri May 8 07:51:46 2009 New Revision: 147274 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147274 Log: 2009-05-08 Paolo Bonzini bonz...@gnu.org PR rtl-optimization/33928 * loop-invariant.c (record_use): Fix vs. || mishap. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-invariant.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #81 from bonzini at gnu dot org 2009-05-08 07:55 --- Created an attachment (id=17825) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17825action=view) speed up fwprop and enable it at -O1 Here is a patch I'm bootstrapping to remove fwprop's usage of UD chains. It does not affect at all the assembly output, it just changes the data structure that is used. compiler.i is probably too big for me, but I tried slatex.i and fwprop was ~2% of compilation time with this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug c++/40066] New: Placement delete not called when constructor throws
This might relate to bug 34158 comment #6.
When throwing an exception in the constructor of an object being allocated as a
result of a call to a (placement) new expression, the corresponding (placement)
operator delete does not get called - unless the new expression is placed
inside a try-catch block AND the exception being throw can be caught by the
catch block.
The expected output of the code below would be (the address' may be different)
allocate 0x804a008
dealloc 0x804a008
allocate 0x804a008
dealloc 0x804a008
terminate called after throwing an instance of 'std::exception'
what(): std::exception
Aborted
but unless the try-catch block is included, it outputs
allocate 0x804a008
dealloc 0x804a008
allocate 0x804a008
terminate called after throwing an instance of 'std::exception'
what(): std::exception
Aborted
Note: If including the try-catch block, but changing the exception-declaration
of the catch to e.g. 'int', the operator delete still does not get called.
#include iostream
using namespace std;
struct Arena {
void* allocate(std::size_t s) {return ::operator new(s);}
void deallocate(void* p) { ::operator delete(p); }
};
inline void* operator new(std::size_t sz, Arena a)
{
void* p = a.allocate(sz);
cout allocate p endl;
return p;
}
inline void operator delete(void* p, Arena a)
{
cout dealloc p endl;
a.deallocate(p);
}
struct Thrower {
Thrower(bool b) { if (b) throw std::exception();}
};
int main()
{
Arena arena;
Thrower* p = new(arena) Thrower(false);
operator delete(p, arena);
//try {
p = new(arena) Thrower(true); // - Memory does not get deallocated
//}
//catch (std::exception) {
//cout catch endl;
//}
return 0;
}
--
Summary: Placement delete not called when constructor throws
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kian dot karas dot dev at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40066
[Bug other/40004] gcc does not install appropriate plugin headers
--- Comment #3 from bradh at frogmouth dot net 2009-05-08 07:58 --- Looks like the install is now dealing with this. -- bradh at frogmouth dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40004
[Bug fortran/39876] module procedure name that collides with the GNU intrinsic
--- Comment #5 from janus at gcc dot gnu dot org 2009-05-08 09:08 --- Subject: Bug 39876 Author: janus Date: Fri May 8 09:08:13 2009 New Revision: 147279 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147279 Log: 2009-05-08 Janus Weil ja...@gcc.gnu.org PR fortran/39876 * intrinsic.c (gfc_is_intrinsic): Do not add the EXTERNAL attribute if the symbol is a module procedure. 2009-05-08 Janus Weil ja...@gcc.gnu.org PR fortran/39876 * gfortran.dg/intrinsic_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/intrinsic_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39876
[Bug fortran/39876] module procedure name that collides with the GNU intrinsic
--- Comment #6 from janus at gcc dot gnu dot org 2009-05-08 09:11 --- Fixed with r147279. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39876
[Bug fortran/38592] eliminate some string comparisons
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2009-05-08 09:30 --- (In reply to comment #3) As a matter of curiosity, do other compilers catch this? Intel does not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38592
[Bug c/40067] New: gcc should use brz(brnz) instead of cmp/be(bne) when possible
Compiling the following function with -O3 gives the following assembly output:
void spin(int volatile* ptr) {
while(*ptr);
return;
}
spin:
.LLFB1:
.register %g2, #scratch
lduw[%o0], %g1 ! 8 *zero_extendsidi2_insn_sp64/2 [length
= 1]
cmp %g1, 0 ! 9 *cmpsi_insn [length = 1]
be,pn %icc, .LL3 ! 10*normal_branch [length = 1]
mov0, %g1 ! 17*movdi_insn_sp64/1 [length = 1]
.LL6:
lduw[%o0], %g2 ! 20*zero_extendsidi2_insn_sp64/2 [length
= 1]
cmp %g2, 0 ! 22*cmpsi_insn [length = 1]
bne,pt %icc, .LL6 ! 23*normal_branch [length = 1]
add%g1, 1, %g1 ! 19*adddi3_sp64/1 [length = 1]
.LL3:
jmp %o7+8 ! 55*return_internal[length = 1]
mov%g1, %o0! 30*movdi_insn_sp64/1 [length = 1]
Manually replacing the cmp/b* pairs with br* instructions gives 10-11% more
iterations/sec on my machine:
.global spin_brz
spin_brz:
.register %g2, #scratch
ld[%o0], %g1
brz,pn%g1, spin_brz_done
clr %g1
spin_brz_again:
ld[%o0], %g2
brnz,pt %g2, spin_brz_again
add %g1, 0x1, %g1
spin_brz_done:
retl
mov %g1, %o0
.size spin_brz, .- spin_brz
--
Summary: gcc should use brz(brnz) instead of cmp/be(bne) when
possible
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC target triplet: sparc-sun-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40067
[Bug middle-end/40067] gcc should use brz(brnz) instead of cmp/be(bne) when possible
--- Comment #1 from scovich at gmail dot com 2009-05-08 09:38 ---
Sorry, the C code should have been:
long spin(int volatile* ptr) {
long rval=0;
while(*ptr) rval++;
return rval;
}
--
scovich at gmail dot com changed:
What|Removed |Added
Component|c |middle-end
Version|unknown |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40067
[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #82 from bonzini at gnu dot org 2009-05-08 09:41 --- Hm, looking at the time reports the patch will save about 30-40% of the fwprop execution time, and should fix the memory hog problem, but will still leave in the 70s needed to compute reaching definitions. I guess it's a step forward for -O2 but borderline for -O1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug tree-optimization/40062] [4.3/4.4/4.5 Regression] high memory usage and compile time in SCEV cprop with -O3
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-08 09:47 ---
The issue is that with follow_ssa_edge_in_condition_phi we end up with
exponential time and space complexity because we have several PHI nodes
in our chain that have a large number of PHI arguments.
The following fixes it
Index: tree-scalar-evolution.c
===
--- tree-scalar-evolution.c (revision 147237)
+++ tree-scalar-evolution.c (working copy)
@@ -1320,10 +1320,12 @@ follow_ssa_edge_in_condition_phi (struct
*evolution_of_loop = evolution_of_branch;
- /* If the phi node is just a copy, do not increase the limit. */
+ /* If the phi node is just a copy, do not increase the limit, otherwise
+ increase it by the number of PHI arguments to avoid exponential
+ complexity. */
n = gimple_phi_num_args (condition_phi);
- if (n 1)
-limit++;
+ limit += n - 1;
+
for (i = 1; i n; i++)
{
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||spop at gcc dot gnu dot org
Target Milestone|--- |4.3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40062
[Bug tree-optimization/40062] [4.3/4.4/4.5 Regression] high memory usage and compile time in SCEV cprop with -O3
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-08 09:52 ---
Or rather
Index: tree-scalar-evolution.c
===
--- tree-scalar-evolution.c (revision 147237)
+++ tree-scalar-evolution.c (working copy)
@@ -1320,11 +1320,7 @@ follow_ssa_edge_in_condition_phi (struct
*evolution_of_loop = evolution_of_branch;
- /* If the phi node is just a copy, do not increase the limit. */
n = gimple_phi_num_args (condition_phi);
- if (n 1)
-limit++;
-
for (i = 1; i n; i++)
{
/* Quickly give up when the evolution of one of the branches is
@@ -1332,10 +1328,12 @@ follow_ssa_edge_in_condition_phi (struct
if (*evolution_of_loop == chrec_dont_know)
return t_true;
+ /* Increase the limit by the PHI argument number to avoid exponential
+time and memory complexity. */
res = follow_ssa_edge_in_condition_phi_branch (i, loop, condition_phi,
halting_phi,
evolution_of_branch,
-init, limit);
+init, limit + i);
if (res == t_false || res == t_dont_know)
return res;
which more follows the logic of using the original limit for the walk
of argument zero.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40062
[Bug tree-optimization/40062] [4.3/4.4/4.5 Regression] high memory usage and compile time in SCEV cprop with -O3
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-08 10:10:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40062
[Bug target/40067] use brz instead of cmp/be with 32-bit values
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-05-08 10:17 --- brz is not used because *ptr is an int, it would be used with a long. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Component|middle-end |target Ever Confirmed|0 |1 GCC target triplet|sparc-sun-solaris2.10 |sparc64-sun-solaris2.10 Last reconfirmed|-00-00 00:00:00 |2009-05-08 10:17:51 date|| Summary|gcc should use brz(brnz)|use brz instead of cmp/be |instead of cmp/be(bne) when |with 32-bit values |possible| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40067
[Bug c/40065] spurious format string warnings
--- Comment #3 from joseph at codesourcery dot com 2009-05-08 10:19 --- Subject: Re: spurious format string warnings On Fri, 8 May 2009, pinskia at gcc dot gnu dot org wrote: is happening here, it is assuming %qE does not take an argument). I don't see an issue really except you really should be compiling a cross compiler with the same version as you are building. I thought that was mentioned somewhere too. There is no such requirement (save maybe to some extent for Ada), it's just that you may get extra warnings using another version, or in stage 1 of a bootstrap (which deliberately does not use -Werror). It's the build-x-target compiler when build != host that must be the same version as the host-x-target compiler you are building, not the build-x-host or build-x-build compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40065
[Bug c/24581] Complex arithmetic on special cases is incorrect.
--- Comment #6 from jsm28 at gcc dot gnu dot org 2009-05-08 10:22 --- Subject: Bug 24581 Author: jsm28 Date: Fri May 8 10:22:08 2009 New Revision: 147281 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147281 Log: PR c/24581 * c-typeck.c (build_binary_op): Handle arithmetic between one real and one complex operand specially. * tree-complex.c (some_nonzerop): Do not identify a real value as zero if flag_signed_zeros. testsuite: * gcc.dg/torture/complex-sign.h: New header. * gcc.dg/torture/complex-sign-add.c, gcc.dg/torture/complex-sign-mixed-add.c, gcc.dg/torture/complex-sign-mixed-div.c, gcc.dg/torture/complex-sign-mixed-mul.c, gcc.dg/torture/complex-sign-mixed-sub.c, gcc.dg/torture/complex-sign-mul.c, gcc.dg/torture/complex-sign-sub.c: New tests. Added: trunk/gcc/testsuite/gcc.dg/torture/complex-sign-add.c trunk/gcc/testsuite/gcc.dg/torture/complex-sign-mixed-add.c trunk/gcc/testsuite/gcc.dg/torture/complex-sign-mixed-div.c trunk/gcc/testsuite/gcc.dg/torture/complex-sign-mixed-mul.c trunk/gcc/testsuite/gcc.dg/torture/complex-sign-mixed-sub.c trunk/gcc/testsuite/gcc.dg/torture/complex-sign-mul.c trunk/gcc/testsuite/gcc.dg/torture/complex-sign-sub.c trunk/gcc/testsuite/gcc.dg/torture/complex-sign.h Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-complex.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581
[Bug c/24581] Complex arithmetic on special cases is incorrect.
--- Comment #7 from jsm28 at gcc dot gnu dot org 2009-05-08 10:34 --- Mixed real/complex arithmetic now handles signed zeros properly and GCC will no longer try to second-guess complex/complex arithmetic as having one half real or imaginary just because the imaginary or real part of that half is zero, so signed zeros should be handled correctly within the constraints of not having imaginary types. This may of course not be what you want in that I is of complex type, not imaginary, but imaginary types have ABI implications and are of very doubtful utility apart from these corner cases. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581
[Bug fortran/38592] eliminate some string comparisons
--- Comment #5 from burnus at gcc dot gnu dot org 2009-05-08 11:25 --- As a matter of curiosity, do other compilers catch this? Intel does not. Sure? If I look at the assembler of ifort 11.1 with -O3, I only see: call __intel_new_proc_init #1.9 call for_set_reentrancy#1.9 call for_write_seq_lis #4.3 And if I'm not mistaken, sunf95 also does not have any call anymore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38592
[Bug target/40067] use brz instead of cmp/be with 32-bit values
--- Comment #3 from scovich at gmail dot com 2009-05-08 11:30 --- What|Removed |Added GCC target triplet|sparc-sun-solaris2.10 |sparc64-sun-solaris2.10 I think this affects 32-bit sparc as well, unless the br* instructions are new in sparcv9 (they don't seem to be). The only difference with v9 seems to be that 32-bit code needs to use ldsw to sign-extend if needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40067
[Bug libstdc++/28406] What should be value of sqrt(complexdouble(-1.0,-0.0))?
--- Comment #9 from paolo dot carlini at oracle dot com 2009-05-08 11:38 --- Really, this can be closed, all the recent branches are fine. I also double checked that another couple of implementations give the same result. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28406
[Bug c++/40068] New: GCC fails to apply dllexport attribute to typeinfo.
Precisely as subject. All other class members and related data (e.g. vtables, synthetic ctors) will be tagged dllexport if the class itself is dllexport, and -export comments will be added listing their symbols in the .drectve section. Typeinfo data alone will not receive the dllexport attribute, because it is not a class member. (Theoretically, I think it counts as a static class data member of type std::type_info, but internally) It is generated as a synthetic POD data type, and hence does not appear to the i386 backend as belonging to the class it represents. The description in bug 17300 suggests that there could be a problem further down the line with dllimporting such typeinfos, but right now they simply can't be referenced outside the enclosing DLL at all, i.e. clients of a DLL can't dynamically cast class pointers to the classes it implements, only routines within the DLL which have local linkage to the typeinfo. This is a separate problem, which I think can be resolved further down the toolchain using pseudo-relocs; I don't think it's a reason not to make export work. -- Summary: GCC fails to apply dllexport attribute to typeinfo. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave dot korn dot cygwin at gmail dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
[Bug c++/40068] GCC fails to apply dllexport attribute to typeinfo.
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-05-08 11:53 --- Created an attachment (id=17826) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17826action=view) Simple testcase It doesn't get much more trivial than this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
[Bug c++/40068] GCC fails to apply dllexport attribute to typeinfo.
--- Comment #2 from dave dot korn dot cygwin at gmail dot com 2009-05-08 11:55 --- To reproduce the bug, compile the attached testcase g++-4 -fpreprocessed -S vti.ii and view the very end of the .s file emitted: .section .drectve .ascii -export:_ZTV12XMLException,data .ascii -export:_ZN12XMLExceptionD2Ev .ascii -export:_ZN12XMLExceptionD1Ev .ascii -export:_ZN12XMLExceptionD0Ev .ascii -export:_ZN12XMLExceptionC1Ev .ascii -export:_ZN12XMLExceptionC2Ev Everything gets exported except the typeinfo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40068
Re: [Bug tree-optimization/40062] [4.3/4.4/4.5 Regression] high memory usage and compile time in SCEV cprop with -O3
+ /* Increase the limit by the PHI argument number to avoid exponential + time and memory complexity. */ This looks good. Thanks, Sebastian
[Bug tree-optimization/40062] [4.3/4.4/4.5 Regression] high memory usage and compile time in SCEV cprop with -O3
--- Comment #4 from sebpop at gmail dot com 2009-05-08 12:12 --- Subject: Re: [4.3/4.4/4.5 Regression] high memory usage and compile time in SCEV cprop with -O3 + Â Â Â /* Increase the limit by the PHI argument number to avoid exponential + Â Â Â Â time and memory complexity. Â */ This looks good. Thanks, Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40062
[Bug middle-end/40069] New: AUTO_INC_DEC not defined correctly in rtl.h
I noticed that AUTO_INC_DEC is defined a bit oddly in gcc/rtl.h. More specifically, the condition does not include HAVE_POST_MODIFY_DISP but it does include HAVE_PRE_MODIFY_DISP twice. Most likely one of these HAVE_PRE_MODIFY_DISP should be a HAVE_POST_MODIFY_DISP. The following is the code snippet from gcc/rtl.h that I am talking about: /* Indicate whether the machine has any sort of auto increment addressing. If not, we can avoid checking for REG_INC notes. */ #if (defined (HAVE_PRE_INCREMENT) || defined (HAVE_PRE_DECREMENT) \ || defined (HAVE_POST_INCREMENT) || defined (HAVE_POST_DECREMENT) \ || defined (HAVE_PRE_MODIFY_DISP) || defined (HAVE_PRE_MODIFY_DISP) \ || defined (HAVE_PRE_MODIFY_REG) || defined (HAVE_POST_MODIFY_REG)) #define AUTO_INC_DEC #endif -- Summary: AUTO_INC_DEC not defined correctly in rtl.h Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ehliar at isy dot liu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40069
[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #83 from bonzini at gnu dot org 2009-05-08 12:22 --- Subject: Bug 33928 Author: bonzini Date: Fri May 8 12:22:30 2009 New Revision: 147282 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147282 Log: 2009-05-08 Paolo Bonzini bonz...@gnu.org PR rtl-optimization/33928 PR 26854 * fwprop.c (use_def_ref, get_def_for_use, bitmap_only_bit_bitween, process_uses, build_single_def_use_links): New. (update_df): Update use_def_ref. (forward_propagate_into): Use get_def_for_use instead of use-def chains. (fwprop_init): Call build_single_def_use_links and let it initialize dataflow. (fwprop_done): Free use_def_ref. (fwprop_addr): Eliminate duplicate call to df_set_flags. * df-problems.c (df_rd_simulate_artificial_defs_at_top, df_rd_simulate_one_insn): New. (df_rd_bb_local_compute_process_def): Update head comment. (df_chain_create_bb): Use the new RD simulation functions. * df.h (df_rd_simulate_artificial_defs_at_top, df_rd_simulate_one_insn): New. * opts.c (decode_options): Enable fwprop at -O1. * doc/invoke.texi (-fforward-propagate): Document this. Modified: trunk/gcc/ChangeLog trunk/gcc/df-problems.c trunk/gcc/df.h trunk/gcc/doc/invoke.texi trunk/gcc/fwprop.c trunk/gcc/opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug tree-optimization/26854] [4.3/4.4/4.5 Regression] Inordinate compile times on large routines
--- Comment #107 from bonzini at gnu dot org 2009-05-08 12:22 --- Subject: Bug 26854 Author: bonzini Date: Fri May 8 12:22:30 2009 New Revision: 147282 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147282 Log: 2009-05-08 Paolo Bonzini bonz...@gnu.org PR rtl-optimization/33928 PR 26854 * fwprop.c (use_def_ref, get_def_for_use, bitmap_only_bit_bitween, process_uses, build_single_def_use_links): New. (update_df): Update use_def_ref. (forward_propagate_into): Use get_def_for_use instead of use-def chains. (fwprop_init): Call build_single_def_use_links and let it initialize dataflow. (fwprop_done): Free use_def_ref. (fwprop_addr): Eliminate duplicate call to df_set_flags. * df-problems.c (df_rd_simulate_artificial_defs_at_top, df_rd_simulate_one_insn): New. (df_rd_bb_local_compute_process_def): Update head comment. (df_chain_create_bb): Use the new RD simulation functions. * df.h (df_rd_simulate_artificial_defs_at_top, df_rd_simulate_one_insn): New. * opts.c (decode_options): Enable fwprop at -O1. * doc/invoke.texi (-fforward-propagate): Document this. Modified: trunk/gcc/ChangeLog trunk/gcc/df-problems.c trunk/gcc/df.h trunk/gcc/doc/invoke.texi trunk/gcc/fwprop.c trunk/gcc/opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
[Bug tree-optimization/40062] [4.3/4.4/4.5 Regression] high memory usage and compile time in SCEV cprop with -O3
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-05-08 12:24 --- Subject: Bug 40062 Author: rguenth Date: Fri May 8 12:24:22 2009 New Revision: 147283 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147283 Log: 2009-05-08 Richard Guenther rguent...@suse.de PR tree-optimization/40062 * tree-scalar-evolution.c (follow_ssa_edge_in_condition_phi): Avoid exponential behavior. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-scalar-evolution.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40062
[Bug tree-optimization/40062] [4.3/4.4/4.5 Regression] high memory usage and compile time in SCEV cprop with -O3
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-05-08 12:28 --- Subject: Bug 40062 Author: rguenth Date: Fri May 8 12:28:01 2009 New Revision: 147284 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147284 Log: 2009-05-08 Richard Guenther rguent...@suse.de PR tree-optimization/40062 * tree-scalar-evolution.c (follow_ssa_edge_in_condition_phi): Avoid exponential behavior. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/tree-scalar-evolution.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40062
[Bug tree-optimization/40062] [4.3 Regression] high memory usage and compile time in SCEV cprop with -O3
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-08 12:39 --- Fixed on trunk and for 4.4.1 sofar. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.3 4.4.0 Known to work||4.4.1 4.5.0 Summary|[4.3/4.4/4.5 Regression]|[4.3 Regression] high memory |high memory usage and |usage and compile time in |compile time in SCEV cprop |SCEV cprop with -O3 |with -O3| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40062
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #17 from dominiq at lps dot ens dot fr 2009-05-08 14:09 --- Thanks to the second program in http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/c6621b97f448b516# I think I have found a false positive for -fwhole-file (unpatched): Implicit None Interface Subroutine sub( a, b, c ) Implicit None Integer, Intent( In ) :: a Integer, Intent( In ) :: b Integer, Intent( In ), Optional :: c End Subroutine sub End Interface call sub(1,2) call sub(1,2,3) end subroutine sub(i,j,k) Implicit None Integer, Intent( In ) :: i Integer, Intent( In ) :: j Integer, Intent( In ), Optional :: k intrinsic present write(*,*)' 3 presence flag ',present(k) write(*,*)' 1st arg ',i write(*,*)' 2nd arg ',j if (present(k)) then write(*,*)' 3rd arg ',k else write(*,*)' 3rd arg is absent' endif return end [ibook-dhum] f90/bug% gfc -fwhole-file no_interface_1.f90 no_interface_1.f90:10.24: call sub(1,2) 1 Error: Unexpected alternate return spec in subroutine call at (1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug tree-optimization/40062] [4.3 Regression] high memory usage and compile time in SCEV cprop with -O3
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-05-08 14:14 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40062
[Bug tree-optimization/40062] [4.3 Regression] high memory usage and compile time in SCEV cprop with -O3
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-05-08 14:14 --- Subject: Bug 40062 Author: rguenth Date: Fri May 8 14:14:25 2009 New Revision: 147288 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147288 Log: 2009-05-08 Richard Guenther rguent...@suse.de PR tree-optimization/40062 * tree-scalar-evolution.c (follow_ssa_edge_in_condition_phi): Avoid exponential behavior. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/tree-scalar-evolution.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40062
[Bug fortran/40070] New: Some math expressions containing exponents fail on a Windows 64 build
Some equations using exponents on Windows XP Professional 64-bit evaluate
incorrectly, but can be computed correctly by splitting up the equation into
multiple statements.
I apologize in advance if this turns out to be just a MinGW bug, but thought
I'd start with gcc first.
I am using MinGW GFortran with the following built-in specs.
Target: x86_64-pc-mingw32
Configured with: ../gcc/configure --target=x86_64-pc-mingw32
--prefix=/c/buildbot/vista64-mingw32/mingw-x86/build/root
--with-sysroot=/c/buildbot/vista64-mingw32/mingw-x86/build/root
--disable-multilib --enable-languages=all,obj-c++
Thread model: win32
gcc version 4.4.0 20090110 (experimental) (GCC)
Here is some sample code that demonstrates the problem:
myfunc.f
Subroutine myfunc(a,b,c,d,e,res1,res2)
Real a,b,c,d,e
Parameter (g = 273.15)
res1 = a*(b/a)**((c-d-g)/(e-d))
res2 = (b/a)**((c-d-g)/(e-d))
res2 = res2 * a
Return
End
Subroutine myfunc2(a,b,c,d,res1,res2)
Real a,b,c,d,res1,res2
res1 = a*(b/c)**d
res2 = (b/c)**d
res2 = a * res2
Return
End
Subroutine myfunc3(a,b,c,d,e,f,g,h,i,res1,res2)
Real a,b,c,d,e,f,g,h,i,res1,res2
res1 = a*((b/(b+c*(d-e)))**((f*g)/(h*i)))*100.
res2 = ((b/(b+c*(d-e)))**((f*g)/(h*i)))*100.
res2 = a*res2
Return
End
main.c
--
#include stdio.h
extern void myfunc(float *a, float *b, float *c, float *d, float *e, float
*res1, float *res2);
extern void myfunc2(float *a, float *b, float *c, float *d, float *res1, float
*res2);
extern void myfunc3(float *a, float *b, float *c, float *d, float *e, float *f,
float *g, float *h, float *i, float *res1, float *res2);
int main( int argc, char *argv[] )
{
float a,b,c,d,e,f,g,h,i,res1,res2;
a=1000.0;
b=850.0;
c=143.204;
d=30.5280;
e=8.2351;
res1 = 0;
res2 = 0;
myfunc(a,b,c,d,e,res1,res2);
printf(Function 1:\n\nresult 1: %f\nresult 2:
%f\n\n,res1,res2);
a=103780.0;
b=253.13005;
c=231.676270;
d=-16.904803;
myfunc2(a,b,c,d,res1,res2);
printf(Function 2:\n\nresult 1: %f\nresult 2:
%f\n\n,res1,res2);
a=1513.25;
b=238.149994;
c=-16.500040;
d=3.2;
e=0;
f=9.806650;
g=20.964399;
h=7614.320313;
i=-0.1065;
myfunc3(a,b,c,d,e,f,g,h,i,res1,res2);
printf(Function 3:\n\nresult 1: %f\nresult 2:
%f\n\n,res1,res2);
return 0;
}
Compiled with the following options:
-fno-uncerscoring
-fno-range-check
-W
-std=f95
--
Summary: Some math expressions containing exponents fail on a
Windows 64 build
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jonathan dot d dot wetherbee at saic dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
[Bug tree-optimization/40071] New: ICE in vectorizable_store, at tree-vect-stmts.c:3108 on mipsel abi=n32 and 64, works at 32
As shown in: http://gcc.gnu.org/ml/gcc-testresults/2009-05/msg00618.html === gnat tests === Running target unix/-mabi=32 === gnat Summary for unix/-mabi=32 === # of expected passes635 # of expected failures 6 Running target unix/-mabi=n32 FAIL: gnat.dg/loop_optimization1.adb (test for excess errors) === gnat Summary for unix/-mabi=n32 === # of expected passes634 # of unexpected failures1 # of expected failures 6 Running target unix/-mabi=64 FAIL: gnat.dg/loop_optimization3.adb execution test === gnat Summary for unix/-mabi=64 === # of expected passes634 # of unexpected failures1 # of expected failures 6 === gnat Summary === # of expected passes1903 # of unexpected failures2 # of expected failures 18 === libgomp tests === So works in abi=32 but ICE in abi=n32 and abi=64 Executing on host: /home/guerby/build-147209/gcc/gnatmake --GCC=/home/guerby/build-147209/gcc/xgcc --GNATBIND=/home/guerby/build-147209/gcc/gnatbind --GNATLINK=/home/guerby/build-147209/gcc/gnatlink -cargs -B/home/guerby/build-147209/gcc -largs --XCC=/home/guerby/build-147209/gcc/xgcc -B/home/guerby/build-147209/gcc -margs --RTS=/home/guerby/build-147209/mips64el-unknown-linux-gnu/./libada -q -f /home/guerby/trunk/gcc/testsuite/gnat.dg/loop_optimization1.adb -O3 -c -S -mabi=n32 -o loop_optimization1.s(timeout = 300) +===GNAT BUG DETECTED==+ | 4.5.0 20090506 (experimental) [trunk revision 147209] (mips64el-unknown-linux-gnu) GCC error:| | in vectorizable_store, at tree-vect-stmts.c:3108 | | Error detected around /home/guerby/trunk/gcc/testsuite/gnat.dg/loop_optimization1.ads:33| | 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: ICE in vectorizable_store, at tree-vect-stmts.c:3108 on mipsel abi=n32 and 64, works at 32 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net GCC build triplet: mipsel-linux-gnu GCC host triplet: mipsel-linux-gnu GCC target triplet: mipsel-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40071
[Bug fortran/40070] Some math expressions containing exponents fail on a Windows 64 build
--- Comment #1 from dominiq at lps dot ens dot fr 2009-05-08 14:55 --- Why are you using a code in C for the tests? If I use the following as the main program real res1, res2 call myfunc(1000.0,850.0,143.204,30.5280,8.2351,res1,res2) print *, res1, res1-res2 call myfunc2(103780.0,253.13005,231.676270,-16.904803,res1,res2) print *, res1, res1-res2 call myfunc3(1513.25,238.149994,-16.500040,3.2,0.0,9.806650,20.964399,7614.320313,-0.1065,res1,res2) print *, res1, res1-res2, spacing(res1) I get 310.40363 0.000 23223.025 0.000 142007.84 1.5625E-02 1.5625E-02 So the difference between the res1 and res2 is either 0 or one LSB. What did you expect? Tests on intel-darwin with or without -m64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
[Bug fortran/40070] Some math expressions containing exponents fail on a Windows 64 build
--- Comment #2 from jonathan dot d dot wetherbee at saic dot com 2009-05-08 15:03 --- I used C code to call the function because the fortran code is being compiled into a C based application. When I run the sample main function, the values are obviously different. Function 1: result 1: 0.000 result 2: 310.403625 Function 2: result 1: 0.000 result 2: 23223.025391 Function 3: result 1: -4171845731254704300. result 2: 142007.828125 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
[Bug target/40067] use brz instead of cmp/be with 32-bit values
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-05-08 15:06 --- I think this affects 32-bit sparc as well, unless the br* instructions are new in sparcv9 (they don't seem to be). Yes, they are new in V9 and operate only on the full 64-bit register. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40067
[Bug fortran/40070] Some math expressions containing exponents fail on a Windows 64 build
--- Comment #3 from kargl at gcc dot gnu dot org 2009-05-08 15:07 --- Fortran bug reports never have a Severity of Blocker unless a GCC Release Manager sets that value. Reset to normal. You forgot to include the actual output you got from running your code. You forgot to include the output you expected to get from the code. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
[Bug fortran/40070] Some math expressions containing exponents fail on a Windows 64 build
--- Comment #4 from jonathan dot d dot wetherbee at saic dot com 2009-05-08 15:27 --- When I run Dominique's main function written in fortran, I get: res1res2 res1-res2 6.09E-24 310.40363 -310.40363 8.92E-23 23223.025 -23223.025 -4.01E-06 142007.59 -142007.59 Oddly enough, just about every other line in this 20,000 line fortran code works fine. It is starting to look like it might just be my build of gcc. I'm running it on an Intel Xeon E5450. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
[Bug fortran/40070] Some math expressions containing exponents fail on a Windows 64 build
--- Comment #5 from dfranke at gcc dot gnu dot org 2009-05-08 15:30 --- You use 'float' in the C routines and 'REAL' in the fortran code. What their respective size? Is float always 4 byte in C? I think default-real-kind on win64 could be 8, not 4? Could also explain why it worked for Dominique, using the same kind everywhere?! You could try and see if using USE ISO_C_BINDING REAL(C_FLOAT) instead of plain REAL makes a difference? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
[Bug fortran/40070] Some math expressions containing exponents fail on a Windows 64 build
--- Comment #6 from dominiq at lps dot ens dot fr 2009-05-08 15:36 --- Adding the print *, ... in the subroutines and mixing C and Fortran, I get: 310.40363 0.000 Function 1: result 1: 310.403625 result 2: 310.403625 23223.025 0.000 Function 2: result 1: 23223.025391 result 2: 23223.025391 142007.84 1.5625E-02 1.5625E-02 Function 3: result 1: 142007.843750 result 2: 142007.828125 I think default-real-kind on win64 could be 8 It would as weird as it was with Crays. default-real-kind is usually the shortest float available, i.e. real(4) on intel procs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
[Bug fortran/40070] Some math expressions containing exponents fail on a Windows 64 build
--- Comment #7 from jonathan dot d dot wetherbee at saic dot com 2009-05-08 15:40 --- Checked the size of a float with sizeof(float) and got 4 bytes. How can I check the size of REAL in fortran? When I try the USE ISO_C_BINDING I get the same result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
[Bug fortran/40070] Some math expressions containing exponents fail on a Windows 64 build
--- Comment #8 from kargl at gcc dot gnu dot org 2009-05-08 15:42 --- (In reply to comment #0) Subroutine myfunc(a,b,c,d,e,res1,res2) Real a,b,c,d,e Parameter (g = 273.15) res1 = a*(b/a)**((c-d-g)/(e-d)) res2 = (b/a)**((c-d-g)/(e-d)) res2 = res2 * a Return End Can you compile the above subroutine with -fdump-tree-original and post the *.original file? a=1513.25; b=238.149994; c=-16.500040; d=3.2; e=0; f=9.806650; g=20.964399; h=7614.320313; i=-0.1065; Have you read Goldberg's paper? What does program a print *, precision(1.e0), digits(1.e0) end program a produce? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
[Bug fortran/40070] Some math expressions containing exponents fail on a Windows 64 build
--- Comment #9 from dominiq at lps dot ens dot fr 2009-05-08 15:49 --- Couldn't it be an alignement problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
[Bug fortran/40070] Some math expressions containing exponents fail on a Windows 64 build
--- Comment #10 from jonathan dot d dot wetherbee at saic dot com
2009-05-08 15:51 ---
When I run the fortran code: print *, precision(1.e0), digits(1.e0)
I get: 6,24
*.original file yields:
myfunc (real(kind=4) a, real(kind=4) b, real(kind=4) c, real(kind=4) d,
real(kind=4) e, real(kind=4) res1, real(kind=4) res2)
{
{
real(kind=4) D.1529;
D.1529 = ((*b / *a));
*res1 = *a * __builtin_powf (D.1529, (*c - *d) -
2.73149993896484375e+2)) / ((*e - *d);
}
{
real(kind=4) D.1530;
D.1530 = ((*b / *a));
*res2 = __builtin_powf (D.1530, (*c - *d) - 2.73149993896484375e+2)) /
((*e - *d);
}
*res2 = *res2 * *a;
goto __return_myfunc;
__return_myfunc:;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
[Bug c/40072] New: Nonoptimal code - CMOVxx %eax,%edi; mov %edi,%eax; retq
Sometimes GCC generate code at end of function:
cmovge %eax,%edi
mov%edi,%eax
retq
but faster:
cmovl %edi,%eax
retq
Example:
# cat test.c
#define MX 0
#define LIM 7
char char_char(char m)
{if(mLIM) return(MX); return(m);}
char char_int(int m)
{if(mLIM) return(MX); return(m);}
char char_uint(unsigned int m)
{if(mLIM) return(MX); return(m);}
char char_long(long m)
{if(mLIM) return(MX); return(m);}
char char_ulong(unsigned long m)
{if(mLIM) return(MX); return(m);}
int int_char(char m)
{if(mLIM) return(MX); return(m);}
int int_int(int m)
{if(mLIM) return(MX); return(m);} // Nonoptimal
int int_uint(unsigned int m)
{if(mLIM) return(MX); return(m);}
int int_long(long m)
{if(mLIM) return(MX); return(m);}
int int_ulong(unsigned long m)
{if(mLIM) return(MX); return(m);}
unsigned int uint_char(char m)
{if(mLIM) return(MX); return(m);}
unsigned int uint_int(int m)
{if(mLIM) return(MX); return(m);}
unsigned int uint_uint(unsigned int m) //Nonoptimal
{if(mLIM) return(MX); return(m);}
unsigned int uint_long(long m)
{if(mLIM) return(MX); return(m);}
unsigned int uint_ulong(unsigned long m)
{if(mLIM) return(MX); return(m);}
long long_char(char m)
{if(mLIM) return(MX); return(m);}
long long_int(int m)
{if(mLIM) return(MX); return(m);}
long long_uint(unsigned int m)
{if(mLIM) return(MX); return(m);}
long long_long(long m) //Nonoptimal
{if(mLIM) return(MX); return(m);}
long long_ulong(unsigned long m)
{if(mLIM) return(MX); return(m);}
unsigned long ulong_char(char m)
{if(mLIM) return(MX); return(m);}
unsigned long ulong_int(int m)
{if(mLIM) return(MX); return(m);}
unsigned long ulong_uint(unsigned int m)
{if(mLIM) return(MX); return(m);}
unsigned long ulong_long(long m)
{if(mLIM) return(MX); return(m);}
unsigned long ulong_ulong(unsigned long m) //Nonoptimal
{if(mLIM) return(MX); return(m);}
# gcc -o t test.c -O2 -c
# objdump -d t
t: file format elf64-x86-64
Disassembly of section .text:
char_char:
0: 89 f8 mov%edi,%eax
2: 40 80 ff 08 cmp$0x8,%dil
6: ba 00 00 00 00 mov$0x0,%edx
b: 0f 4d c2cmovge %edx,%eax--- It's ok! Optimal
e: c3 retq
f: 90 nop
skip...
0060 int_int:
60: 83 ff 08cmp$0x8,%edi
63: b8 00 00 00 00 mov$0x0,%eax
68: 0f 4d f8cmovge %eax,%edi--- Nonoptimal
6b: 89 f8 mov%edi,%eax--- Nonoptimal
6d: c3 retq
6e: 66 90 xchg %ax,%ax
skip...
00c0 uint_uint:
c0: 83 ff 08cmp$0x8,%edi
c3: b8 00 00 00 00 mov$0x0,%eax
c8: 0f 43 f8cmovae %eax,%edi--- Nonoptimal
cb: 89 f8 mov%edi,%eax--- Nonoptimal
cd: c3 retq
ce: 66 90 xchg %ax,%ax
skip...
0120 long_long:
120: 48 83 ff 08 cmp$0x8,%rdi
124: b8 00 00 00 00 mov$0x0,%eax
129: 48 0f 4d f8 cmovge %rax,%rdi--- Nonoptimal
12d: 48 89 f8mov%rdi,%rax--- Nonoptimal
130: c3 retq
skip...
0190 ulong_ulong:
190: 48 83 ff 08 cmp$0x8,%rdi
194: b8 00 00 00 00 mov$0x0,%eax
199: 48 0f 43 f8 cmovae %rax,%rdi--- Nonoptimal
19d: 48 89 f8mov%rdi,%rax--- Nonoptimal
1a0: c3 retq
--
Summary: Nonoptimal code - CMOVxx %eax,%edi; mov%edi,%eax;
retq
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vvv at ru dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40072
[Bug target/40072] Nonoptimal code - CMOVxx %eax,%edi; mov %edi,%eax; retq
-- steven at gcc dot gnu dot org changed: What|Removed |Added CC||steven at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-08 16:08:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40072
[Bug fortran/40070] Some math expressions containing exponents fail on a Windows 64 build
--- Comment #11 from kargl at gcc dot gnu dot org 2009-05-08 16:18 --- (In reply to comment #10) When I run the fortran code: print *, precision(1.e0), digits(1.e0) I get: 6,24 Read Goldberg's paper. I suspect you have either a rounding issue (hint, see Goldberg, the number 6 and your input list) or whatever __builtin_powf maps to on your system is broken? I lay my money on the former. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40070
[Bug c++/40066] Placement delete not called when constructor throws
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-08 16:21 --- see 15.3 P 9: If no matching handler is found in a program, the function terminate() is called; whether or not the stack is unwound before this call to terminate() is implemenation-defined (15.5.1) So we define it as not unwinding but we don't document this. *** This bug has been marked as a duplicate of 20976 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40066
[Bug c++/20976] when terminate is called, stack is not unwinded
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-05-08 16:21 --- *** Bug 40066 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||kian dot karas dot dev at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20976
[Bug tree-optimization/40073] New: Vector short/char shifts generate sub-optimal code
On machines like the x86_64/i386 with -msse2 option or powerpc with the -maltivec option that support vector 8-bit/16-bit shift instructions, GCC generates suboptimal code for variable shifts. Rather than generate the native instruction, the compiler converts the vector to V4SI vector, does the shift, and then converts the vector back to V16QI/V8HI mode. I speculate that this is due to the normal binary operator rules being done to bring both sides to the same type. Shifts and rotates are different in that the right hand side is an int type. -- Summary: Vector short/char shifts generate sub-optimal code Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: meissner at linux dot vnet dot ibm dot com GCC build triplet: x86_64-unknown-linux-gnu, powerpc64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu, powerpc64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu, powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073
[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code
--- Comment #2 from meissner at linux dot vnet dot ibm dot com 2009-05-08 17:02 --- Created an attachment (id=17828) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17828action=view) Replacement test case that doesn't need -DTYPE to show the bug Replacement test case. -- meissner at linux dot vnet dot ibm dot com changed: What|Removed |Added Attachment #17827|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073
[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code
--- Comment #3 from meissner at linux dot vnet dot ibm dot com 2009-05-08 17:03 --- Created an attachment (id=17829) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17829action=view) Powerpc example code This code was compiled with -O3 -maltivec. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073
[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code
--- Comment #4 from meissner at linux dot vnet dot ibm dot com 2009-05-08 17:04 --- Created an attachment (id=17830) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17830action=view) X86_64 example code This code was compiled with an x86_64 compiler with the -O3 -msse3 options. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073
[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code
--- Comment #5 from meissner at linux dot vnet dot ibm dot com 2009-05-08 17:06 --- Created an attachment (id=17831) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17831action=view) Vectorizer verbose output This is the output from the Powerpc compiler with -fdump-tree-vect -ftree-vectorizer-verbose=10 -fdump-tree-vect -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073
[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code
--- Comment #1 from meissner at linux dot vnet dot ibm dot com 2009-05-08 16:59 --- Created an attachment (id=17827) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17827action=view) test case This code is an example of the code that generates sub-optimal code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073
[Bug tree-optimization/40071] ICE assert aliasing in vectorizable_store, at tree-vect-stmts.c:3108 on mipsel abi=n32 and 64, works at 32
--- Comment #1 from laurent at guerby dot net 2009-05-08 18:08 --- According to line information the assert that fails is about aliasing: /* If accesses through a pointer to vectype do not alias the original memory reference we have a problem. This should never happen. */ gcc_assert (alias_sets_conflict_p (get_alias_set (data_ref), get_alias_set (gimple_assign_lhs (stmt; -- laurent at guerby dot net changed: What|Removed |Added Summary|ICE in vectorizable_store, |ICE assert aliasing in |at tree-vect-stmts.c:3108 on|vectorizable_store, at tree- |mipsel abi=n32 and 64, works|vect-stmts.c:3108 on mipsel |at 32 |abi=n32 and 64, works at 32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40071
[Bug tree-optimization/40071] ICE assert aliasing in vectorizable_store, at tree-vect-stmts.c:3108 on mipsel abi=n32 and 64, works at 32
--- Comment #2 from laurent at guerby dot net 2009-05-08 18:15 --- The Ada test was added by Eric Botcazou: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01204.html The predictive commoning pass performs load hoisting on an expression that can throw, thus breaking the CFG; of course this is -fnon-call-exceptions at work. The proposed fix is to do what LIM does, i.e. to punt on these expressions. Might not be the same issue again though. -- laurent at guerby dot net changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40071
[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2
--- Comment #8 from danglin at gcc dot gnu dot org 2009-05-08 18:21 --- Introduced in revision 146894: 2009-04-28 Andrew Pinski pins...@gmail.com PR target/39929 * config/darwin.c (machopic_gen_offset): Check currently_expanding_to_rtl if current_ir_type returns IR_GIMPLE. * config/arm/arm.c (require_pic_register): Likewise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39978
[Bug c/36892] Support __attribute__((deprecated(text string)))
--- Comment #6 from hjl at gcc dot gnu dot org 2009-05-08 18:45 --- Subject: Bug 36892 Author: hjl Date: Fri May 8 18:44:50 2009 New Revision: 147293 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147293 Log: gcc/ 2009-05-08 H.J. Lu hongjiu...@intel.com Andrew Morrow a...@google.com PR c/36892 * c-common.c (c_common_attribute_table): Permit deprecated attribute to take an optional argument. (handle_deprecated_attribute): If the optional argument to __attribute__((deprecated)) is not a string ignore the attribute and emit a warning. * c-decl.c (grokdeclarator): Updated warn_deprecated_use call. * c-typeck.c (build_component_ref): Likewise. (build_external_ref): Likewise. * toplev.c (warn_deprecated_use): Add an attribute argument. Emit the message associated with __attribute__((deprecated)). * toplev.h (warn_deprecated_use): Updated. * doc/extend.texi: Document new optional parameter to __attribute__((deprecated)) gcc/cp/ 2009-05-08 H.J. Lu hongjiu...@intel.com PR c/36892 * call.c (build_call_a): Updated warn_deprecated_use call. (build_over_call): Likewise. * decl.c (grokdeclarator): Likewise. (grokparms): Likewise. * semantics.c (finish_id_expression): Likewise. * typeck.c (build_class_member_access_expr): Likewise. (finish_class_member_access_expr): Likewise. gcc/testsuite/ 2009-05-08 H.J. Lu hongjiu...@intel.com PR c/36892 * g++.dg/warn/deprecated-6.C: New. * gcc.dg/deprecated-4.c: Likewise. * gcc.dg/deprecated-5.c: Likewise. * gcc.dg/deprecated-6.c: Likewise. Added: trunk/gcc/testsuite/g++.dg/warn/deprecated-6.C trunk/gcc/testsuite/gcc.dg/deprecated-4.c trunk/gcc/testsuite/gcc.dg/deprecated-5.c trunk/gcc/testsuite/gcc.dg/deprecated-6.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/c-decl.c trunk/gcc/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/decl.c trunk/gcc/cp/semantics.c trunk/gcc/cp/typeck.c trunk/gcc/doc/extend.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/toplev.c trunk/gcc/toplev.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36892
[Bug c++/33858] Spurious warning with anonymous namespace and anonymous types
--- Comment #3 from tobi at gcc dot gnu dot org 2009-05-08 18:53 ---
Note that the C-like equivalent doesn't warn (at least with g++ 4.1.2):
$ cat user/t.cc
namespace {
struct {
} t;
}
static struct {
} s;
$ g++ -c user/t.cc
user/t.cc:3: warning: non-local variable 'unnamed::anonymous struct
unnamed::t' uses anonymous type
$
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
CC||tobi at gcc dot gnu dot org
Last reconfirmed|2007-12-02 22:24:33 |2009-05-08 18:53:49
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33858
[Bug c++/39126] Missing move constructor call (C++0x rvalue references)
--- Comment #3 from gbrammer at gmx dot de 2009-05-08 19:17 --- Well, I am sure that it shouldn't be created, but rereading the spec (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html 12.8) I noticed that this bug is not in g++, but by design. I had hoped that rvalue references were a replacement for the ability to pass temporaries to non-const references present in g++ up to version 4.1 and Microsoft's C++ compilers, but apparently one has to be very very careful using them. Well, at least I now only have to worry about the code, not the compiler. -- gbrammer at gmx dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39126
[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-05-08 19:35 --- (In reply to comment #8) Introduced in revision 146894: Interesting you don't hit the bug I described in PR 40031. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39978
[Bug c++/39862] [4.5 Regression] verify_eh_tree failed with -O2
--- Comment #5 from hubicka at ucw dot cz 2009-05-08 19:44 --- Subject: Re: [4.5 Regression] verify_eh_tree failed with -O2 This is very sick side case of updating prev_try pointer in duplicate_eh_edges. I think it is clear that maintaining prev_try pointer just to slightly speed up the lookup in foreach_reachable_handler is highly impractical. Once the other bugfix to EH code is in the tree, I will test patch removing prev_try and replacing its use by find_prev_try. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39862
[Bug c++/40074] New: Compile failure in ocrad-0.18
I;m running gcc-4.4.0 (built with default optimization flags, but with additional optimizations) and was testing it on ocrad-0.18 (admittedly with lots of optimization): I get g++ -march=pentium4 -msse2 -mfpmath=sse -O3 -ffast-math -funroll-loops -fomit-frame-pointer -floop-interchange -floop-strip-mine -floop-block -c -o track.o track.cc track.cc: In member function 'void Track::set_track(const std::vectorRectangle, std::allocatorRectangle )': track.cc:219: internal compiler error: in vect_get_vec_def_for_operand, at tree-vect-transform.c:1999 I'll attach the preprocessed source separately. -- Summary: Compile failure in ocrad-0.18 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ronis at ronispc dot chem dot mcgill dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40074
[Bug c++/40074] Compile failure in ocrad-0.18
--- Comment #1 from ronis at ronispc dot chem dot mcgill dot ca 2009-05-08 20:16 --- Created an attachment (id=17832) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17832action=view) Preprocessed source of source that triggers ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40074
[Bug middle-end/39301] ICE in register_overhead, at bitmap.c:115
--- Comment #6 from lucier at math dot purdue dot edu 2009-05-08 20:27 --- Just for more information, I now hit this on x86_64-unknown-linux-gnu with the compiler pythagoras-32% /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /tmp/lucier/gcc/mainline/configure --enable-checking=release --prefix=/pkgs/gcc-mainline --enable-languages=c --enable-gather-detailed-mem-stats Thread model: posix gcc version 4.5.0 20090508 (experimental) [trunk revision 147288] (GCC) on the compiler.i test case with /pkgs/gcc-mainline/bin/gcc -save-temps -I../include -I. -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 -frename-registers -fno-move-loop-invariants -fforward-propagate -DHAVE_CONFIG_H -D___PRIMAL -D___LIBRARY -c compiler.i -ftime-report -fmem-report rename-no-move-loop-invariants-forward-propagate-report-new -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39301
[Bug middle-end/39978] [4.5 Regression] SEGV compiling libiberty/regex.c in stage2
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2009-05-08 20:34 --- Subject: Re: [4.5 Regression] SEGV compiling libiberty/regex.c in stage2 Interesting you don't hit the bug I described in PR 40031. I tested the following in the regression search: 146971 bad 146908 bad 146900 bad 146894 bad 146893 ok 146892 ok 146876 ok 146845 ok The bug in PR 40031 was reported at 147121, so maybe things have changed. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39978
[Bug target/40072] Nonoptimal code - CMOVxx %eax,%edi; mov %edi,%eax; retq
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement GCC target triplet||x86_64-*-* Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40072
[Bug tree-optimization/40073] Vector short/char shifts generate sub-optimal code
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Severity|normal |enhancement Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40073
[Bug tree-optimization/40074] Compile failure in ocrad-0.18
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-08 20:41 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40074
[Bug c++/40007] [4.5 regression] specialization causes access problem in primary template
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-05-08 20:52
---
Debugging cc1plus for this slightly reduced program:
templatetypename T
struct x
{
protected:
typedef int type;
};
templatetypename T
struct y : public xT
{
typename xT::type z;
};
template
struct yvoid : public xvoid
{
typedef xvoid::type z;
};
template class yint;
shows the explicit instantiation of yint calls
perform_typedefs_access_check() which calls
enforce_access() with decl = xvoid::type.
That's wrong, it should be xint::type - somehow the wrong typedef is
added to the list of types to check for the yint specialisation.
(gdb) bt
#0 enforce_access (basetype_path=0x2b643180, decl=0x2b641cc0,
diag_decl=0x2b641cc0) at ../../src/gcc/gcc/cp/call.c:4447
#1 0x004acabc in perform_typedefs_access_check (
tmpl=value optimized out, targs=0x2b6429c0)
at ../../src/gcc/gcc/cp/pt.c:6960
#2 0x004b827b in instantiate_class_template (type=0x2b644240)
at ../../src/gcc/gcc/cp/pt.c:7443
#3 0x004edf00 in complete_type (type=0x2b644240)
at ../../src/gcc/gcc/cp/typeck.c:130
#4 0x004b062c in do_type_instantiation (t=0x2b644240,
storage=0x0, complain=1) at ../../src/gcc/gcc/cp/pt.c:15011
#5 0x004e0f11 in cp_parser_explicit_instantiation (
parser=0x2b4b59b0) at ../../src/gcc/gcc/cp/parser.c:10812
#6 0x004e6905 in cp_parser_declaration (parser=0x2b4b59b0)
at ../../src/gcc/gcc/cp/parser.c:8013
#7 0x004e6caa in cp_parser_declaration_seq_opt (parser=0x2b4b59b0)
at ../../src/gcc/gcc/cp/parser.c:7927
#8 0x004e7527 in c_parse_file () at ../../src/gcc/gcc/cp/parser.c:3029
#9 0x005557fa in c_common_parse_file (
set_yydebug=value optimized out) at ../../src/gcc/gcc/c-opts.c:1272
#10 0x007519e2 in toplev_main (argc=13, argv=0x7fffe8a8)
at ../../src/gcc/gcc/toplev.c:979
#11 0x2ace24ca in __libc_start_main () from /lib/libc.so.6
#12 0x0048216a in _start () at ../sysdeps/x86_64/elf/start.S:113
(gdb) n
4448 gcc_assert (TREE_CODE (basetype_path) == TREE_BINFO);
(gdb)
4450 if (!accessible_p (basetype_path, decl, true))
(gdb)
4452 if (TREE_PRIVATE (decl))
(gdb)
4454 else if (TREE_PROTECTED (decl))
(gdb)
4455error (%q+#D is protected, diag_decl);
(gdb)
pr40007.cc: In instantiation of yint:
pr40007.cc:20: instantiated from here
pr40007.cc:5: error: typedef int xvoid::type is protected
4458 error (within this context);
(gdb)
pr40007.cc:10: error: within this context
4463}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40007
[Bug tree-optimization/40074] [4.4/4.5 Regression] Compile failure in ocrad-0.18
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-05-08 20:59 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.4.0 Known to work||4.3.3 Last reconfirmed|-00-00 00:00:00 |2009-05-08 20:59:57 date|| Summary|Compile failure in ocrad- |[4.4/4.5 Regression] Compile |0.18|failure in ocrad-0.18 Target Milestone|--- |4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40074
[Bug tree-optimization/40074] [4.4/4.5 Regression] Compile failure in ocrad-0.18
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-05-08 21:00 --- Created an attachment (id=17833) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17833action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40074
[Bug c/36892] Support __attribute__((deprecated(text string)))
--- Comment #7 from hjl dot tools at gmail dot com 2009-05-08 21:07 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36892
[Bug c++/40075] New: deprecated(xxx) doesn't work on function parameter
deprecated(xxx) doesn't work on function parameter with C++: [...@gnu-6 gcc]$ cat /tmp/foo.i typedef int INT2 __attribute__((deprecated(Please avoid INT2))); int f5(INT2 x); [...@gnu-6 gcc]$ ./xgcc -B./ -S /tmp/foo.i /tmp/foo.i:2: warning: INT2 is deprecated: Please avoid INT2 [...@gnu-6 gcc]$ ./g++ -B./ -S /tmp/foo.i /tmp/foo.i:2: warning: INT2 is deprecated [...@gnu-6 gcc]$ -- Summary: deprecated(xxx) doesn't work on function parameter Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ 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=40075
[Bug c++/40076] New: g++ should not permit types to be defined in compound literals
This is invalid C++:
struct s1 { int i; } *p;
int i = ((struct s2 { int j; } *)p)-j;
foo.cc:2: error: types may not be defined in casts
By analogy, this should be invalid C++:
int i = (struct s3 { int j; }) { 1 }.j;
Currently g++ accepts it. Compound literals are an extension to C++, so there
are no documented rules about them. However, it seems to be that when it comes
to defining new types, they should be consistent with casts.
--
Summary: g++ should not permit types to be defined in compound
literals
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40076
[Bug c++/40076] g++ should not permit types to be defined in compound literals
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-08 21:41 --- But is defining a new type in a compound literal legal for C99? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40076
[Bug c++/40076] g++ should not permit types to be defined in compound literals
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-08 21:51 --- Oh, types are valid to be defined in casts in C. You did not mention that in the bug report so I thought you could not define a type in C either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40076
[Bug c++/40076] g++ should not permit types to be defined in compound literals
--- Comment #3 from ian at airs dot com 2009-05-08 22:19 --- Yeah, in C you can define a struct type in a type cast and then use it later. Cool stuff. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40076
[Bug c++/40077] New: Duplicated deprecated message
C++ compiler will issue the duplicated deprecated message:
[...@gnu-6 gcc]$ cat /tmp/fun.i
int f1 () __attribute__((deprecated));
int
foo ()
{
return f1 ();
}
[...@gnu-6 gcc]$ ./xgcc -B./ -S /tmp/fun.i
/tmp/fun.i: In function foo:
/tmp/fun.i:6: warning: f1 is deprecated (declared at /tmp/fun.i:1)
[...@gnu-6 gcc]$ ./g++ -B./ -S /tmp/fun.i
/tmp/fun.i: In function int foo():
/tmp/fun.i:6: warning: int f1() is deprecated (declared at /tmp/fun.i:1)
/tmp/fun.i:6: warning: int f1() is deprecated (declared at /tmp/fun.i:1)
[...@gnu-6 gcc]$
--
Summary: Duplicated deprecated message
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
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=40077
[Bug c++/17729] [4.3/4.4/4.5 Regression] Duplicate __attribute__((deprecated)) warning
--- Comment #14 from pinskia at gcc dot gnu dot org 2009-05-08 22:21 --- *** Bug 40077 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729
[Bug c++/40077] Duplicated deprecated message
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-08 22:21 --- *** This bug has been marked as a duplicate of 17729 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40077
[Bug tree-optimization/40049] Incorrect tree made for vector shifted by constant on powerpc, spu
--- Comment #10 from meissner at gcc dot gnu dot org 2009-05-08 22:39 --- Subject: Bug 40049 Author: meissner Date: Fri May 8 22:38:49 2009 New Revision: 147298 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147298 Log: Fix PR 40049 Added: trunk/gcc/testsuite/gcc.dg/vect/vect-shift-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40049
[Bug middle-end/40078] New: passing label to inline asm i constraint generates bad code
Somewhat to my surprise, the gcc accepts the following inline asm syntax:
asm(jmp %0 : : i(some_label));
The output is what you'd expect: assuming some_label (in C/C++) is associated
with the assembler label .LLBF4 gives:
jmp .LLBF4
Unfortunately, the optimizer plays havoc with things by happily eliminating the
code associated with that label if it is otherwise unused. Consider the
following code:
static inline int foo() { return 10; }
int could_be_anything;
long test_label(int volatile* ptr) {
int rval = 0;
int dummy = 5;
static void* const gotos[2] = {DONE, ERROR};
asm volatile(jmp %0\n\t nop: :i(ERROR),i(foo),r(dummy));
//goto *gotos[could_be_anything];
DONE:
return rval;
ERROR:
rval = 1;
goto DONE;
}
This function should return 1 after jumping from ERROR to DONE. Instead, the
code for ERROR is eliminated by the optimizer; you either get a return value of
zero or an infinite loop depending on whether the label started below or above
the asm block (I get the latter):
foo:
jmp %o7+8
mov10, %o0
.size foo, .-foo
test_label:
.LL4:
.LL5:
mov 5, %g1
! 8 test_label.c 1
jmp .LL4
nop
! 0 2
jmp %o7+8
mov0, %o0
.size test_label, .-test_label
The compiler correctly recognizes that both dummy and foo are in use and does
not eliminate them, but ERROR gets the axe unless the computed goto is enabled.
In theory the inconsistency should be easy to fix -- just mark the label as
in-use if it gets passed to a live inline asm block (exactly how functions and
variables are currently treated). If for some reason that's impossible or
undesirable, it should at least generate a diagnostic.
--
Summary: passing label to inline asm i constraint generates
bad code
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: scovich at gmail dot com
GCC target triplet: sparc-sun-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40078
[Bug middle-end/40078] passing label to inline asm i constraint generates bad code
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-08 22:52 --- This is by design, first inline-asm is not allowed to change control flow. Second labels can be moved if they are not used normally in the program. In this case they are not used normally. Addresses of labels are only designed for computed gotos and any other use causes undefined behavior of their placement. Yes: asm(jmp %0 : : i(some_label)); is valid as the address of a label is a constant but GCC does not look into the string and how you use it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40078
[Bug c++/40075] deprecated(xxx) doesn't work on function parameter
--- Comment #1 from hjl dot tools at gmail dot com 2009-05-08 23:15 --- Another difference between C and C++: [...@gnu-6 tmp]$ cat bad.i typedef int INT2 __attribute__((deprecated)); int f5(INT2 x); int f6(INT2 x) __attribute__((deprecated)); [...@gnu-6 tmp]$ gcc -S bad.i bad.i:2: warning: INT2 is deprecated bad.i:3: warning: INT2 is deprecated [...@gnu-6 tmp]$ g++ -S bad.i bad.i:2: warning: INT2 is deprecated (declared at bad.i:1) [...@gnu-6 tmp]$ -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40075
[Bug middle-end/40078] passing label to inline asm i constraint generates bad code
--- Comment #2 from scovich at gmail dot com 2009-05-08 23:24 --- Sorry to bring this back up, but I'm not sure if comments show up in a meaningful way on closed bugs... 1. where does is it documented that inline asm can't change control flow? I can't find it in the info pages, nor anywhere in google except this bug and another which was also resolved-invalid with a comment that it's clearly commented. The docs say you can do control flow within a single asm (if your assembler supports local labels), but the only other mention is the part that says you can't jump between asm blocks because the compiler has no way to know that you did it. 2. It makes sense that anything related to stack frames (ret, call) would be a snake pit, but is there some reason why local gotos are inherently unsafe? Unlike an asm-asm jump, the compiler knows all the places control might go (you can only jump out once, after all), and presumably users wouldn't pass in labels they don't intend to use. It seems like the compiler could just treat the asm block accepting labels as a basic block containing a computed goto -- control could fall out the bottom of the block or jump any of the labels which were passed in. 3. Supporting local gotos would help work around the annoyance of getting condition codes out of an asm block efficiently -- pass in the label to a branch instruction and voila! In any case, I'm happy to accept a, go away, but would be extremely interested to hear the reasons behind this limitation given that it seems so close to working on accident. -- scovich at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40078
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
--- Comment #11 from dougkwan at google dot com 2009-05-09 01:21 --- We saw this also in gcc-4.3.1 on target arm-none-eabi. -- dougkwan at google dot com changed: What|Removed |Added CC||dougkwan at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug middle-end/27313] Does not emit conditional moves for stores
--- Comment #6 from wilson at gcc dot gnu dot org 2009-05-09 01:21 --- It looks like this was fixed by Michael Matz here: http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html This patch was added to gcc-4.3, and the gcc-4.2 branch is closed, so I think this bug should be closed resolved. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27313
[Bug middle-end/40079] New: [4.5 Regression] Revision 147294 caused extra failures
On Linux/ia32, revision 147294: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00268.html caused FAIL: /export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libjava/testsuite/TestLeak.exe execution - /export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libjava/testsuite/TestLeak.exe FAIL: g++.dg/opt/thunk3.C (test for excess errors) -- Summary: [4.5 Regression] Revision 147294 caused extra failures Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end 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=40079
