[Bug fortran/37833] New: internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108
> gfortran -ffree-form -fdefault-real-8 -D SEQ -c output.F90 -save-temps output.F90: In function outp: output.F90:1: internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. For Debian GNU/Linux specific bug reporting instructions, see . > gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --with-tune=pentium4 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) -- Summary: internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108 Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: markus dot airila at vtt dot fi GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37833
[Bug fortran/37833] internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108
--- Comment #1 from markus dot airila at vtt dot fi 2008-10-15 07:27 --- Created an attachment (id=16496) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16496&action=view) Preprocessed source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37833
[Bug fortran/37833] internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108
--- Comment #4 from markus dot airila at vtt dot fi 2008-10-15 07:29 --- Created an attachment (id=16499) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16499&action=view) Source file containing modules -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37833
[Bug fortran/37833] internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108
--- Comment #5 from markus dot airila at vtt dot fi 2008-10-15 07:30 --- Created an attachment (id=16500) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16500&action=view) Source file containing modules -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37833
[Bug fortran/37833] internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108
--- Comment #6 from markus dot airila at vtt dot fi 2008-10-15 07:30 --- Created an attachment (id=16501) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16501&action=view) Source file containing modules -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37833
[Bug fortran/37833] internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108
--- Comment #7 from markus dot airila at vtt dot fi 2008-10-15 07:32 --- Created an attachment (id=16502) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16502&action=view) Source file containing modules -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37833
[Bug fortran/37833] internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108
--- Comment #3 from markus dot airila at vtt dot fi 2008-10-15 07:29 --- Created an attachment (id=16498) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16498&action=view) Source file containing modules -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37833
[Bug fortran/37833] internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108
--- Comment #8 from markus dot airila at vtt dot fi 2008-10-15 07:33 --- Created an attachment (id=16503) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16503&action=view) Source file containing modules -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37833
[Bug fortran/37833] internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108
--- Comment #2 from markus dot airila at vtt dot fi 2008-10-15 07:28 --- Created an attachment (id=16497) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16497&action=view) Original source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37833
[Bug fortran/37834] New: write(*,'(f0.0)') 0.0 prints "." instead of "0."
Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/57938d5454a90397/589afd86ab2aab9b The program write(*,'(f0.0)') 0.0 end outputs . with gfortran and 0. with ifort, NAG f95, g95, openf95. -- Summary: write(*,'(f0.0)') 0.0 prints "." instead of "0." Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37834
[Bug fortran/37835] New: -fno-automatic does not work for derived types with default initalizer
The following program prints
- "2 42" with gfortran -fno-automatic
- "2 2" with NAG f95 -save and ifort -save
Expected: The SAVE is also implied for derived types with default initializer.
The problem is really the initializer as the dump shows:
static struct t myt = {.i=42}; <<< OK since SAVE
{
struct t t.1;
t.1.i = 42; << OK if not SAVE
myt = t.1;
}
subroutine foo(n)
integer :: n
type t
integer :: i = 42
end type t
type(t) :: myt
if(n==1) myt%i = 2
print *, myt%i
end subroutine foo
call foo(1)
call foo(2)
end
--
Summary: -fno-automatic does not work for derived types with
default initalizer
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37835
[Bug fortran/37835] -fno-automatic does not work for derived types with default initalizer
--- Comment #1 from burnus at gcc dot gnu dot org 2008-10-15 08:30 --- Forgot to add: Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/57938d5454a90397/589afd86ab2aab9b -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37835
[Bug fortran/37836] New: ICE in gfc_trans_auto_array_allocation
Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/57938d5454a90397/589afd86ab2aab9b The following program gives an ICE: test.f90:14: internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:4115 The bug has been found by James Van Buskirk. ! Automatic data object function fun4a(x) real x,fun4a ! real y(nint(exp(3.0))) real y(minval([nint(exp(3.0))])) fun4a = y(1) y = x end function fun4a function fun4b(x) real x,fun4b ! real y(nint(exp(3.0))) real y(minval([nint(exp(3.0))])) save fun4b = y(1) y = x end function fun4b -- Summary: ICE in gfc_trans_auto_array_allocation Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 32834 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37836
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #14 from jakub at gcc dot gnu dot org 2008-10-15 09:08 --- The problem is that thread_across_edge figures out that the fabs (al[0] - al[1]) < 1.e-5 test is unnecessary, always yields false for +-1.0, by substituting the values in record_temporary_equivalences_from_stmts_at_dest, but doesn't actually optimize all the computations to constants. If the threading duplicated block is used just for one constant, not two, then fab optimizes the __builtin_pow call into a constant and dom2 optimizes the rest into a constant. But as we have two different constants leading to the same block, nothing in GCC optimizes it out, and given -fno-signed-zeros and the testcase very much depending on the sign of zeros, the outcome is different from what the compiler expected. While GCC perhaps could optimize: # cn_43 = PHI <-1.0e+0(3), 1.0e+0(9)> D.1267_44 = __builtin_pow (cn_43, 2.0e+0); D.1268_46 = 1.0e+0 - D.1267_44; D.1269_47 = __builtin_sqrt (D.1268_46); into a constant with some smarter fab or dom hack for multiple constants, it can't already optimize the following: D.1270_49 = __builtin_atan2 (D.1269_47, cn_43); or D.1270_49 = __builtin_atan2 (0.0, cn_43); because that yields different values for -1 and 1. While even the partial optimization would cure this testcase and is perhaps an useful enhancement, I believe it is just wrong to compile this part of calculix with -ffast-math and you get what you deserve. `-fno-signed-zeros' Allow optimizations for floating point arithmetic that ignore the signedness of zero. IEEE arithmetic specifies the behavior of distinct +0.0 and -0.0 values, which then prohibits simplification of expressions such as x+0.0 or 0.0*x (even with `-ffinite-math-only'). This option implies that the sign of a zero result isn't significant. is quite clear and this testcase definitely relies on +0 vs. -0 difference heavily. So I'd say this should be closed as INVALID. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||law at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug middle-end/37461] [4.4 Regression] ICE in find_or_generate_expression, at tree-ssa-pre.c:2691
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-15 11:09 --- Fixed by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140460 -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37461
[Bug c++/35483] GCC on AIX doesn't support dollar in symbols name.
--- Comment #8 from dje at gcc dot gnu dot org 2008-10-15 12:25 --- Subject: Bug 35483 Author: dje Date: Wed Oct 15 12:23:55 2008 New Revision: 141134 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141134 Log: PR target/35483 Based on patches by Laurent Vivier. * xcoffout.h (DBX_FINISH_STABS): Translate dollar sign to underscore. * config/rs6000/rs6000-protos.h (rs6000_xcoff_strip_dollar): Declare. * config/rs6000/xcoff.h (ASM_DECLARE_FUNCTION_NAME): Translate dollar sign to underscore. (ASM_OUTPUT_EXTERNAL): Same. (ASM_OUTPUT_LABELREF): New. * config/rs6000/rs6000.c (rs6000_xcoff_strip_dollar): New. * config/rs6000/aix51.h (TARGET_USE_JCR_SECTION): Define. * config/rs6000/aix52.h (TARGET_USE_JCR_SECTION): Define. * config/rs6000/aix53.h (TARGET_USE_JCR_SECTION): Define. * config/rs6000/aix61.h (TARGET_USE_JCR_SECTION): Define. Modified: trunk/gcc/config/rs6000/aix51.h trunk/gcc/config/rs6000/aix52.h trunk/gcc/config/rs6000/aix53.h trunk/gcc/config/rs6000/aix61.h trunk/gcc/config/rs6000/rs6000-protos.h trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/xcoff.h trunk/gcc/xcoffout.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35483
[Bug target/26397] Program crashes when rethrowing exception
--- Comment #9 from dje at gcc dot gnu dot org 2008-10-15 12:29 --- Proper G++ exception handling requires shared libraries. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26397
[Bug target/37137] [4.4 Regression] unrecognized command line option "-minterlink-mips16"
--- Comment #6 from bonzini at gnu dot org 2008-10-15 12:42 --- fixed in r141135 -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37137
[Bug target/26397] Program crashes when rethrowing exception
--- Comment #10 from stuart dot downing at sungard dot com 2008-10-15 13:43 --- (In reply to comment #9) > Proper G++ exception handling requires shared libraries. > Why? This is not the case on other target platforms. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26397
[Bug fortran/37723] wrong result for left-right hand side array overlap and (possibly) negative strides
--- Comment #7 from dominiq at lps dot ens dot fr 2008-10-15 14:33 --- The patch on comment #6 works as advertised without regression (i686-apple-darwin9). Thanks for the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37723
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #17 from jakub at gcc dot gnu dot org 2008-10-15 09:47 ---
Testcase where only one constant, not two alternative constants, are on the
entry of the threaded bb.
extern int printf (const char *, ...);
void
__attribute__((noinline))
test (double cn, int *neig)
{
double tt, al[3];
*neig = 3;
if (__builtin_fabs(cn) > 1.)
cn = -1.;
tt = __builtin_atan2 (__builtin_sqrt (1. - __builtin_pow (cn, 2.)), cn)
* 3.333e-1;
al[0] = __builtin_cos (tt);
al[1] = __builtin_cos (2.0943951023931944 + tt);
al[2] = __builtin_cos (4.1887902047863879 + tt);
if ((__builtin_fabs ( al[0] - al[1]) < 1.e-5)
|| (__builtin_fabs (al[0] - al[2]) < 1.e-5)
|| (__builtin_fabs (al[1] - al[2]) < 1.e-5))
*neig = 2;
}
int
main ()
{
int neig;
test (-1.0, &neig);
printf ("neig = %d\n", neig);
if (neig != 2)
__builtin_abort ();
test (1.0, &neig);
printf ("neig = %d\n", neig);
if (neig != 2)
__builtin_abort ();
test (-2.0, &neig);
printf ("neig = %d\n", neig);
if (neig != 2)
__builtin_abort ();
return 0;
}
At -O2 -funsafe-math-optimizations, before ccp3 we have:
D.1262_38 = __builtin_pow (-1.0e+0, 2.0e+0);
D.1263_40 = 1.0e+0 - D.1262_38;
D.1264_41 = __builtin_sqrt (D.1263_40);
D.1265_43 = __builtin_atan2 (D.1264_41, -1.0e+0);
tt_45 = D.1265_43 *
3.33314829616256247390992939472198486328125e-1;
D.1266_46 = __builtin_cos (tt_45);
D.1267_47 = tt_45 + 2.094395102393194374457152662216685712337493896484375e+0;
D.1268_48 = __builtin_cos (D.1267_47);
D.1269_49 = tt_45 + 4.1887902047863878607358856243081390857696533203125e+0;
D.1270_50 = __builtin_cos (D.1269_49);
and neither ccp3, nor pre is able to optimize it out, only fab optimizes the
first call (pow) and then dom2 handles the rest.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.5.0 |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug middle-end/37838] New: gcc ignores FENV_ACCESS pragma set to ON
gcc currently ignores FENV_ACCESS pragma set to ON, and generate incorrect code
in such cases. Before gcc recognizes this pragma, the -frounding-math option
should probably be on by default. For instance, consider the following code.
#include
#include
#include
#include
#pragma STDC FENV_ACCESS ON
static void tstall (void)
{
volatile double x = DBL_MIN;
printf ("%.20g = %.20g\n", 1.0 + DBL_MIN, 1.0 + x);
printf ("%.20g = %.20g\n", 1.0 - DBL_MIN, 1.0 - x);
}
int main (void)
{
#ifdef FE_TONEAREST
printf ("Rounding to nearest\n");
if (fesetround (FE_TONEAREST))
printf ("Error\n");
else
tstall ();
#endif
#ifdef FE_TOWARDZERO
printf ("Rounding toward 0\n");
if (fesetround (FE_TOWARDZERO))
printf ("Error\n");
else
tstall ();
#endif
#ifdef FE_DOWNWARD
printf ("Rounding toward -inf\n");
if (fesetround (FE_DOWNWARD))
printf ("Error\n");
else
tstall ();
#endif
#ifdef FE_UPWARD
printf ("Rounding toward +inf\n");
if (fesetround (FE_UPWARD))
printf ("Error\n");
else
tstall ();
#endif
return 0;
}
By default, I get incorrect results:
Rounding to nearest
1 = 1
1 = 1
Rounding toward 0
1 = 1
1 = 0.99988898
Rounding toward -inf
1 = 1
1 = 0.99988898
Rounding toward +inf
1 = 1.000222
1 = 1
If I add the -frounding-math option, I get correct results:
Rounding to nearest
1 = 1
1 = 1
Rounding toward 0
1 = 1
0.99988898 = 0.99988898
Rounding toward -inf
1 = 1
0.99988898 = 0.99988898
Rounding toward +inf
1.000222 = 1.000222
1 = 1
--
Summary: gcc ignores FENV_ACCESS pragma set to ON
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37838
[Bug target/26397] Program crashes when rethrowing exception
--- Comment #11 from dje at gcc dot gnu dot org 2008-10-15 15:34 --- You can try manually linking the program with libsupc++.a as well: http://codesynthesis.com/~boris/blog/2006/12/10/statically-linking-on-aix/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26397
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-10-15 15:43 --- *** Bug 37838 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||vincent at vinc17 dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
[Bug middle-end/37838] gcc ignores FENV_ACCESS pragma set to ON
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-15 15:43 --- *** This bug has been marked as a duplicate of 34678 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37838
[Bug tree-optimization/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.
--- Comment #22 from spop at gcc dot gnu dot org 2008-10-15 16:14 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37686
[Bug tree-optimization/37686] [4.4 Regression] Building of CPU2000's bzip2 with peak flags with -mcpu=power4 fails with an ICE.
--- Comment #23 from spop at gcc dot gnu dot org 2008-10-15 16:14 --- Subject: Bug 37686 Author: spop Date: Wed Oct 15 16:13:33 2008 New Revision: 141141 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141141 Log: 2008-10-15 Sebastian Pop <[EMAIL PROTECTED]> PR tree-optimization/37686 * testsuite/gcc.dg/tree-ssa/pr37686.c: New. * tree-loop-linear.c (linear_transform_loops): Build a loop nest vector. Pass it to lambda_compute_access_matrices. * tree-data-ref.h (struct access_matrix): Store the loop nest relative to which it encodes the information. (AM_LOOP_NEST_NUM): Renamed AM_LOOP_NEST. (am_vector_index_for_loop): Reimplemented: iterate over the loop nest for finding the loop index in the access matrix. (lambda_compute_access_matrices): Update declaration. * lambda-code.c (build_access_matrix): Pass the loop nest and record it. (lambda_compute_access_matrices): Same. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr37686.c Modified: trunk/gcc/ChangeLog trunk/gcc/lambda-code.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.h trunk/gcc/tree-loop-linear.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37686
[Bug middle-end/37828] [graphite] ICE in expand_scalar_variables_expr, at graphite.c:3421 with -floop-block
--- Comment #6 from spop at gcc dot gnu dot org 2008-10-15 16:18 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37828
[Bug middle-end/37828] [graphite] ICE in expand_scalar_variables_expr, at graphite.c:3421 with -floop-block
--- Comment #7 from spop at gcc dot gnu dot org 2008-10-15 16:19 --- Subject: Bug 37828 Author: spop Date: Wed Oct 15 16:17:45 2008 New Revision: 141142 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141142 Log: 2008-10-15 Sebastian Pop <[EMAIL PROTECTED]> Harsha Jagasia <[EMAIL PROTECTED]> PR tree-optimization/37828 * testsuite/gcc.dg/graphite/pr37828.c: New. * graphite.c (graphite_trans_loop_block): Do not loop block single nested loops. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr37828.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37828
[Bug middle-end/37485] [graphite] Disconnecting exit edge in process of code generation
--- Comment #14 from spop at gcc dot gnu dot org 2008-10-15 16:25 --- Subject: Bug 37485 Author: spop Date: Wed Oct 15 16:24:15 2008 New Revision: 141143 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141143 Log: 2008-10-15 Jan Sjodin <[EMAIL PROTECTED]> Harsha Jagasia <[EMAIL PROTECTED]> PR tree-optimization/37485 * graphite.c (gmp_cst_to_tree): Moved. (iv_stack_entry_is_constant): New. (iv_stack_entry_is_iv): New. (loop_iv_stack_push): Renamed to loop_iv_stack_push_iv. (loop_iv_stack_insert_constant): New. (loop_iv_stack_pop): Use new datatpype. (loop_iv_stack_get_iv): Same. (loop_iv_stack_get_iv_from_name): Same. (loop_iv_stack_debug): Renamed to debug_loop_iv_stack. (loop_iv_stack_patch_for_consts): New. (loop_iv_stack_remove_constants): New. (graphite_create_new_loop): Use loop_iv_stack_push_iv. (translate_clast): Call loop_iv_stack_patch_for_consts and loop_iv_stack_remove_constants. (gloog): Use new datatype. Redirect construction edge to end block to avoid accidental deletion. * graphite.h (enum iv_stack_entry_kind): New. Tag for data in iv stack entry. (union iv_stack_entry_data): New. Data in iv stack entry. (struct iv_stack_entry): New. Datatype for iv stack entries. 2008-10-15 Sebastian Pop <[EMAIL PROTECTED]> * tree-data-ref.c (stmt_simple_memref_p): Fix memleak. * graphite.c (free_scop): Same. (build_scops): Same. (free_scattering): New. (build_cloog_prog): Call free_scattering. (patch_phis_for_virtual_defs): Fix memleak. (graphite_trans_bb_strip_mine): Same. (limit_scops): Same. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr37485.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite.c trunk/gcc/graphite.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37485
[Bug middle-end/37485] [graphite] Disconnecting exit edge in process of code generation
--- Comment #15 from spop at gcc dot gnu dot org 2008-10-15 16:27 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37485
[Bug libfortran/34670] bounds checking for array intrinsics
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-10-15 16:29 --- Subject: Bug 34670 Author: tkoenig Date: Wed Oct 15 16:27:58 2008 New Revision: 141144 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141144 Log: 2008-10-15 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/34670 * intrinsics/reshape_generic.c: Add bounds checking. * m4/reshape.m4: Likewise. * generated/reshape_c10.c: Regenerated. * generated/reshape_c16.c: Regenerated. * generated/reshape_c4.c: Regenerated. * generated/reshape_c8.c: Regenerated. * generated/reshape_i16.c: Regenerated. * generated/reshape_i4.c: Regenerated. * generated/reshape_i8.c: Regenerated. * generated/reshape_r10.c: Regenerated. * generated/reshape_r16.c: Regenerated. * generated/reshape_r4.c: Regenerated. * generated/reshape_r8.c: Regenerated. * generated/spread_r4.c: Regenerated. 2008-10-15 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/34670 * gfortran.dg/reshape_3.f90: New test. * gfortran.dg/reshape_4.f90: New test. * gfortran.dg/reshape_order_1.f90: Use correct shape. * gfortran.dg/reshape_order_2.f90: Likewise. * gfortran.dg/reshape_order_3.f90: Likewise. * gfortran.dg/reshape_order_4.f90: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/reshape_order_1.f90 trunk/gcc/testsuite/gfortran.dg/reshape_order_2.f90 trunk/gcc/testsuite/gfortran.dg/reshape_order_3.f90 trunk/gcc/testsuite/gfortran.dg/reshape_order_4.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/generated/reshape_c10.c trunk/libgfortran/generated/reshape_c16.c trunk/libgfortran/generated/reshape_c4.c trunk/libgfortran/generated/reshape_c8.c trunk/libgfortran/generated/reshape_i16.c trunk/libgfortran/generated/reshape_i4.c trunk/libgfortran/generated/reshape_i8.c trunk/libgfortran/generated/reshape_r10.c trunk/libgfortran/generated/reshape_r16.c trunk/libgfortran/generated/reshape_r4.c trunk/libgfortran/generated/reshape_r8.c trunk/libgfortran/generated/spread_r4.c trunk/libgfortran/intrinsics/reshape_generic.c trunk/libgfortran/m4/reshape.m4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34670
[Bug libfortran/34670] bounds checking for array intrinsics
--- Comment #9 from tkoenig at gcc dot gnu dot org 2008-10-15 16:31 --- Matmul and spread are also done. Still a few to go... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34670
[Bug c++/35483] GCC on AIX doesn't support dollar in symbols name.
--- Comment #9 from dje at gcc dot gnu dot org 2008-10-15 16:55 --- Patch committed. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35483
[Bug target/27880] [4.2/4.3/4.4 regression] undefined reference to `_Unwind_GetIPInfo'
--- Comment #29 from sje at cup dot hp dot com 2008-10-15 17:06 --- See http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00647.html for a discussion and proposed patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880
[Bug tree-optimization/37664] [4.4 Regression] ice in remove_range_assertions, at tree-vrp.c:5116
--- Comment #8 from jakub at gcc dot gnu dot org 2008-10-15 11:59 --- Anyway, the ICE is caused by PR37327. As 139890rguenth if (TREE_CODE (val) == INTEGER_CST 139890rguenth && TREE_OVERFLOW (val)) 139890rguenth val = build_int_cst_wide (TREE_TYPE (val), 139890rguenth TREE_INT_CST_LOW (val), TREE_INT_CST_HIGH (val)); removes overflow flag from loc->val, any_uint > UINT_MAX comparison folds to false, which triggers the: tree cond = fold (ASSERT_EXPR_COND (rhs)); gcc_assert (cond != boolean_false_node); assertion in remove_range_assertions. To fix this, we could either: 1) in register_new_assert_for if TREE_OVERFLOW was set on original val try to fold_binary the condition and if it yields false, don't add the assertion candidate at all 2) in process_assert_insertions_for don't add anything if the condition folds to false 3) remove the folding and assert in remove_range_assertions -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37664
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #16 from jakub at gcc dot gnu dot org 2008-10-15 09:38 --- After discussion with richi, I'd like to turn this into an enhancement request for 4.5 to extend PRE/SCCVN to be able to optimize that: # cn_43 = PHI <-1.0e+0(4), 1.0e+0(3)> D.1267_44 = __builtin_pow (cn_43, 2.0e+0); into a constant. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org, rguenth at gcc dot gnu ||dot org Target Milestone|4.4.0 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug fortran/37821] [4.4 Regression] gfortran is ignoring #includes with the syntax
--- Comment #7 from burnus at gcc dot gnu dot org 2008-10-15 09:29 --- Patch does not work - the "." causes problems as a "include" (not "#include") does not work anymore: The "." is not included. Still there is the issue about the order "." should be searched before the "-I" paths and it is not needed to be added for "#include" but only for "include". The latter can be solved by calling in this case in "gfc_add_include_path" only "add_path_to_list (&include_dirs" and not "gfc_cpp_add_include_path" but I fear that also the order for include_dirs has to be changed as well as OPT_I / -I come before the filename processing in gfc_post_options. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37821
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #20 from law at redhat dot com 2008-10-15 17:36 --- Subject: Re: [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math jakub at gcc dot gnu dot org wrote: > --- Comment #14 from jakub at gcc dot gnu dot org 2008-10-15 09:08 > --- > The problem is that thread_across_edge figures out that the fabs (al[0] - > al[1]) > < 1.e-5 test is unnecessary, always yields false for +-1.0, by substituting > the > values in record_temporary_equivalences_from_stmts_at_dest, but doesn't > actually optimize all the computations to constants. It's not safe to actually optimize the computations because the equivalences we use may be specific to a path through the CFG. One could easily argue that when these situations arise we've actually identified a missed optimization in PRE. Or one could argue that the block in question ought to be a candidate for duplication and tacking onto the end of its predecessor blocks (super-block formation) which would expose the partial redundancy at the cost of duplicating statements. I've generally not been a fan of super-block formation as, IMHO, PRE catches the vast majority of things super-block formation would and PRE doesn't have the code expansion problems that the super-block approach does. [ ... ] > is quite clear and this testcase definitely relies on +0 vs. -0 difference > heavily. > > So I'd say this should be closed as INVALID. > > Or kept open as an enhancement request for PRE. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug tree-optimization/37664] [4.4 Regression] ice in remove_range_assertions, at tree-vrp.c:5116
--- Comment #9 from rguenther at suse dot de 2008-10-15 12:15 --- Subject: Re: [4.4 Regression] ice in remove_range_assertions, at tree-vrp.c:5116 On Wed, 15 Oct 2008, jakub at gcc dot gnu dot org wrote: > --- Comment #8 from jakub at gcc dot gnu dot org 2008-10-15 11:59 --- > Anyway, the ICE is caused by PR37327. As > 139890rguenth if (TREE_CODE (val) == INTEGER_CST > 139890rguenth && TREE_OVERFLOW (val)) > 139890rguenth val = build_int_cst_wide (TREE_TYPE (val), > 139890rguenth TREE_INT_CST_LOW (val), > TREE_INT_CST_HIGH (val)); > removes overflow flag from loc->val, any_uint > UINT_MAX comparison folds to > false, which triggers the: > tree cond = fold (ASSERT_EXPR_COND (rhs)); > gcc_assert (cond != boolean_false_node); > assertion in remove_range_assertions. To fix this, we could either: > 1) in register_new_assert_for if TREE_OVERFLOW was set on original val try to >fold_binary the condition and if it yields false, don't add the assertion >candidate at all > 2) in process_assert_insertions_for don't add anything if the condition folds >to false > 3) remove the folding and assert in remove_range_assertions 4) make fold fold any_overflowed_uint > UINT_MAX to boolean_false_node which IMHO makes more sense. We should try getting rid of spurious overflow flags in the IL, one way is to make them have no effect. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37664
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #21 from dberlin at gcc dot gnu dot org 2008-10-15 17:55 --- Subject: Re: [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math > > It already does (I fixed that recently), but we only phi-translate during > insertion and we > don't insert for that case, as obviously there is no partial redundancy. True, but if it discovered all the new phi arguments would be constant it used to create a new phi node with the new constant values and let eliminate replace the old calculation with the new phi node. Maybe it only did this if all the constants ended up the same value, but it would be trivial to do it if all the arguments are constant, regardless of whether they are the same value. :) --Dan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug ada/37840] New: ICE compiling Ada
Building Ada itself so I suspect this should show up on Solaris. If this isn't enough information, tell me what to add. /home/joel/work-gnat/svn/b-gcc2-sparc/./gcc/xgcc -B/home/joel/work-gnat/svn/b-gcc2-sparc/./gcc/ -nostdinc -B/home/joel/work-gnat/svn/b-gcc2-sparc/sparc-rtems4.10/newlib/ -isystem /home/joel/work-gnat/svn/b-gcc2-sparc/sparc-rtems4.10/newlib/targ-include -isystem /home/joel/work-gnat/svn/gcc/newlib/libc/include -B/home/joel/work-gnat/svn//install/sparc-rtems4.10/bin/ -B/home/joel/work-gnat/svn//install/sparc-rtems4.10/lib/ -isystem /home/joel/work-gnat/svn//install/sparc-rtems4.10/include -isystem /home/joel/work-gnat/svn//install/sparc-rtems4.10/sys-include -c -g -O2 -W -Wall -gnatpg a-clrefi.adb -o a-clrefi.o +===GNAT BUG DETECTED==+ | 4.4.0 20081014 (experimental) [trunk revision 141108] (sparc-unknown-rtems4.10) GCC error:| | in vt_add_function_parameters, at var-tracking.c:3176| | Error detected around a-clrefi.adb:526 | | 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 compiling Ada Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org GCC target triplet: sparc-rtems4.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37840
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #19 from rguenther at suse dot de 2008-10-15 13:18 --- Subject: Re: [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math On Wed, 15 Oct 2008, dberlin at dberlin dot org wrote: > > > --- Comment #18 from dberlin at gcc dot gnu dot org 2008-10-15 13:06 > --- > Subject: Re: [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math > > Making PRE do this is somewhat trivial. > Just extend fully_constant_expression to fold builtins, like it used > to, and it should just DTRT. It already does (I fixed that recently), but we only phi-translate during insertion and we don't insert for that case, as obviously there is no partial redundancy. Richard. > On Wed, Oct 15, 2008 at 5:38 AM, jakub at gcc dot gnu dot org > <[EMAIL PROTECTED]> wrote: > > > > > > --- Comment #16 from jakub at gcc dot gnu dot org 2008-10-15 09:38 > > --- > > After discussion with richi, I'd like to turn this into an enhancement > > request > > for 4.5 to extend PRE/SCCVN to be able to optimize that: > > # cn_43 = PHI <-1.0e+0(4), 1.0e+0(3)> > > D.1267_44 = __builtin_pow (cn_43, 2.0e+0); > > into a constant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug tree-optimization/37717] [4.4 Regression] verify_ssa failed for legal C++ with -O2
--- Comment #5 from bonzini at gnu dot org 2008-10-15 12:41 --- Subject: Bug 37717 Author: bonzini Date: Wed Oct 15 12:40:05 2008 New Revision: 141135 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141135 Log: 2008-10-15 Paolo Bonzini <[EMAIL PROTECTED]> PR bootstrap/37717 * Makefile.in (LIBCFLAGS): Remove. (FLAGS_TO_PASS): Don't mention it. (COMPILE.c, MULTIOSDIR): Replace it with CFLAGS. Modified: trunk/libiberty/ChangeLog trunk/libiberty/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37717
[Bug ada/37840] ICE compiling Ada [regression]
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-10-15 18:04 --- This is most likely a dup of bug 37815. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37840
[Bug fortran/37723] wrong result for left-right hand side array overlap and (possibly) negative strides
--- Comment #6 from pault at gcc dot gnu dot org 2008-10-15 09:20 --- Created an attachment (id=16504) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16504&action=view) A fix for the PR The attachment is neither boostrapped nor regtested but does fix the PR. I am not able to do anything with it until Sunday, at least. If anybody wishes to take it up, please do so. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37723
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #18 from dberlin at gcc dot gnu dot org 2008-10-15 13:06 --- Subject: Re: [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math Making PRE do this is somewhat trivial. Just extend fully_constant_expression to fold builtins, like it used to, and it should just DTRT. On Wed, Oct 15, 2008 at 5:38 AM, jakub at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #16 from jakub at gcc dot gnu dot org 2008-10-15 09:38 > --- > After discussion with richi, I'd like to turn this into an enhancement request > for 4.5 to extend PRE/SCCVN to be able to optimize that: > # cn_43 = PHI <-1.0e+0(4), 1.0e+0(3)> > D.1267_44 = __builtin_pow (cn_43, 2.0e+0); > into a constant. > > > -- > > jakub at gcc dot gnu dot org changed: > > What|Removed |Added > > CC||dberlin at gcc dot gnu dot > ||org, rguenth at gcc dot gnu > ||dot org > Target Milestone|4.4.0 |4.5.0 > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug rtl-optimization/37286] [4.4 regression] gfortran, trunk: ICE subst_stack_regs_pat, at reg-stack.c:1537
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-10-15 18:23 --- I can no longer reproduce this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37286
[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always
--- Comment #5 from jason at gcc dot gnu dot org 2008-10-15 18:28 --- Contra Mark, this seems like a WONTFIX to me. g++ assumes that if a class has a vtable, if we're going to do anything with it we'll create an object of that type at some point, which will use the vtable, and so we'll get the debug info. This seems like a reasonable assumption to me; the only time it will be invalid is with trivial examples like this. No real code would try to cast to class2* when nothing in the program ever creates a class2. And if the user is doing something funny, there's the -femit-class-debug-always flag. In this case, we aren't omitting debug info for class2 because it's unused, we're omitting it because we know we'll emit it elsewhere. I think adding the -femit-class-debug-always flag to the testcase is the correct fix for the testsuite failure; changing the compiler to emit debug information more frequently would create a regression in debug info size. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #22 from rguenther at suse dot de 2008-10-15 18:33 ---
Subject: Re: [4.4 Regression] calculix gets
wrong answer for -O1 -ffast-math
On Wed, 15 Oct 2008, dberlin at dberlin dot org wrote:
> --- Comment #21 from dberlin at gcc dot gnu dot org 2008-10-15 17:55
> ---
> Subject: Re: [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
>
> >
> > It already does (I fixed that recently), but we only phi-translate during
> > insertion and we
> > don't insert for that case, as obviously there is no partial redundancy.
>
> True, but if it discovered all the new phi arguments would be constant
> it used to create a new phi node with the new constant values and let
> eliminate replace the old calculation with the new phi node.
>
> Maybe it only did this if all the constants ended up the same value,
> but it would be trivial to do it if all the arguments are constant,
> regardless of whether they are the same value.
> :)
Well, we already do for
int foo (int b)
{
double i;
if (b)
i = 4;
else
i = 9;
return __builtin_sqrt(i);
}
:
# i_1 = PHI <4.0e+0(5), 9.0e+0(3)>
# prephitmp.11_7 = PHI <2.0e+0(5), 3.0e+0(3)>
# prephitmp.12_8 = PHI <2(5), 3(3)>
D.1238_5 = prephitmp.11_7;
D.1237_6 = prephitmp.12_8;
return D.1237_6;
at least. Somebody needs to look why it doesn't happen for the
testcase posted.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug tree-optimization/37837] New: missed PRE
Testcase where only one constant, not two alternative constants, are on the
entry of the threaded bb.
extern int printf (const char *, ...);
void
__attribute__((noinline))
test (double cn, int *neig)
{
double tt, al[3];
*neig = 3;
if (__builtin_fabs(cn) > 1.)
cn = -1.;
tt = __builtin_atan2 (__builtin_sqrt (1. - __builtin_pow (cn, 2.)), cn)
* 3.333e-1;
al[0] = __builtin_cos (tt);
al[1] = __builtin_cos (2.0943951023931944 + tt);
al[2] = __builtin_cos (4.1887902047863879 + tt);
if ((__builtin_fabs ( al[0] - al[1]) < 1.e-5)
|| (__builtin_fabs (al[0] - al[2]) < 1.e-5)
|| (__builtin_fabs (al[1] - al[2]) < 1.e-5))
*neig = 2;
}
int
main ()
{
int neig;
test (-1.0, &neig);
printf ("neig = %d\n", neig);
if (neig != 2)
__builtin_abort ();
test (1.0, &neig);
printf ("neig = %d\n", neig);
if (neig != 2)
__builtin_abort ();
test (-2.0, &neig);
printf ("neig = %d\n", neig);
if (neig != 2)
__builtin_abort ();
return 0;
}
cn == -1 is available.
--
Summary: missed PRE
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37837
[Bug c/37106] [4.4 Regression] ICE with -fpic or -fPIC: in mems_in_disjoint_alias_sets_p, at alias.c:278
--- Comment #13 from ghazi at gcc dot gnu dot org 2008-10-15 18:37 --- (In reply to comment #11) > Digging the archives the failures on x86_64-linux when using -fpic or -fPIC > appeared between: > http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg02246.html > and > http://gcc.gnu.org/ml/gcc-testresults/2008-07/msg02337.html > Kaveh do you have a way to know the corresponding revisions? Sorry no. I see that some postings have the revision number in the postiong subject, but I don't know how to do that nor why everyone isn't having that done by default. It would have been useful in retrospect. :-/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37106
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #23 from rguenther at suse dot de 2008-10-15 18:43 ---
Subject: Re: [4.4 Regression] calculix gets
wrong answer for -O1 -ffast-math
On Wed, 15 Oct 2008, rguenther at suse dot de wrote:
> --- Comment #22 from rguenther at suse dot de 2008-10-15 18:33 ---
> Subject: Re: [4.4 Regression] calculix gets
> wrong answer for -O1 -ffast-math
>
> On Wed, 15 Oct 2008, dberlin at dberlin dot org wrote:
>
> > --- Comment #21 from dberlin at gcc dot gnu dot org 2008-10-15 17:55
> > ---
> > Subject: Re: [4.4 Regression] calculix gets wrong answer for -O1
> > -ffast-math
> >
> > >
> > > It already does (I fixed that recently), but we only phi-translate during
> > > insertion and we
> > > don't insert for that case, as obviously there is no partial redundancy.
> >
> > True, but if it discovered all the new phi arguments would be constant
> > it used to create a new phi node with the new constant values and let
> > eliminate replace the old calculation with the new phi node.
> >
> > Maybe it only did this if all the constants ended up the same value,
> > but it would be trivial to do it if all the arguments are constant,
> > regardless of whether they are the same value.
> > :)
>
> Well, we already do for
>
> int foo (int b)
> {
> double i;
> if (b)
> i = 4;
> else
> i = 9;
> return __builtin_sqrt(i);
> }
>
> :
> # i_1 = PHI <4.0e+0(5), 9.0e+0(3)>
> # prephitmp.11_7 = PHI <2.0e+0(5), 3.0e+0(3)>
> # prephitmp.12_8 = PHI <2(5), 3(3)>
> D.1238_5 = prephitmp.11_7;
> D.1237_6 = prephitmp.12_8;
> return D.1237_6;
Ok, for return __builtin_pow (i, i) it doesn't work because we
do not register phi-translations that result in constants (translating
i does) and then we run into the if (seen) guard and fail to
phi-translate.
Either we should register phi-translations for them or not do that
seen test for expr->kind == NAME (it shouldn't recurse for that, no?).
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #24 from dberlin at gcc dot gnu dot org 2008-10-15 18:50
---
Subject: Re: [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
On Wed, Oct 15, 2008 at 2:43 PM, rguenther at suse dot de
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #23 from rguenther at suse dot de 2008-10-15 18:43 ---
> Subject: Re: [4.4 Regression] calculix gets
> wrong answer for -O1 -ffast-math
>
> On Wed, 15 Oct 2008, rguenther at suse dot de wrote:
>
>> --- Comment #22 from rguenther at suse dot de 2008-10-15 18:33 ---
>> Subject: Re: [4.4 Regression] calculix gets
>> wrong answer for -O1 -ffast-math
>>
>> On Wed, 15 Oct 2008, dberlin at dberlin dot org wrote:
>>
>> > --- Comment #21 from dberlin at gcc dot gnu dot org 2008-10-15 17:55
>> > ---
>> > Subject: Re: [4.4 Regression] calculix gets wrong answer for -O1
>> > -ffast-math
>> >
>> > >
>> > > It already does (I fixed that recently), but we only phi-translate during
>> > > insertion and we
>> > > don't insert for that case, as obviously there is no partial redundancy.
>> >
>> > True, but if it discovered all the new phi arguments would be constant
>> > it used to create a new phi node with the new constant values and let
>> > eliminate replace the old calculation with the new phi node.
>> >
>> > Maybe it only did this if all the constants ended up the same value,
>> > but it would be trivial to do it if all the arguments are constant,
>> > regardless of whether they are the same value.
>> > :)
>>
>> Well, we already do for
>>
>> int foo (int b)
>> {
>> double i;
>> if (b)
>> i = 4;
>> else
>> i = 9;
>> return __builtin_sqrt(i);
>> }
>>
>> :
>> # i_1 = PHI <4.0e+0(5), 9.0e+0(3)>
>> # prephitmp.11_7 = PHI <2.0e+0(5), 3.0e+0(3)>
>> # prephitmp.12_8 = PHI <2(5), 3(3)>
>> D.1238_5 = prephitmp.11_7;
>> D.1237_6 = prephitmp.12_8;
>> return D.1237_6;
>
> Ok, for return __builtin_pow (i, i) it doesn't work because we
> do not register phi-translations that result in constants (translating
> i does) and then we run into the if (seen) guard and fail to
> phi-translate.
>
> Either we should register phi-translations for them
We should be.
REmember we used to always create names for constants, and then we
removed that because the constants were valid arguments for GIMPLE
expressions anyway.
Now that we don't always produce NAME, we should be allowing
registration of translations that result in CONSTANT.
Otherwise we will also miss partial redundancies where one phi
arguments evaluates to constant, as well, because when it comes time
to look it up, it will come up with no translation, and we will assume
it's nnot partially redundant.
--Dan
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug c/37106] [4.4 Regression] ICE with -fpic or -fPIC: in mems_in_disjoint_alias_sets_p, at alias.c:278
--- Comment #14 from dominiq at lps dot ens dot fr 2008-10-15 18:54 --- > ... I don't know how to do that ... What I do is to edit the file gcc/DATESTAMP to have [revision number] date instead of just date The minor drawback is that there is a conflict with svn update each time the date stamp changes. > why everyone isn't having that done by default ... May be you can ask on the gcc list why this is not done automatically. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37106
[Bug debug/28064] .debug_str is used only when optimizing
--- Comment #3 from drow at gcc dot gnu dot org 2008-10-15 18:57 --- Then let's forget about the -fmerge-constants question and mark this fixed. -- drow at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28064
[Bug c/37106] [4.4 Regression] ICE with -fpic or -fPIC: in mems_in_disjoint_alias_sets_p, at alias.c:278
--- Comment #15 from dominiq at lps dot ens dot fr 2008-10-15 18:58 --- I have forgotten to say that I also put the revision numbers in the name of the logs of the tests so I can grep the files for some pattern and have the list of the revisions for which it appears. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37106
[Bug c++/37590] g++ should emit different debug info for variable's type
--- Comment #8 from drow at gcc dot gnu dot org 2008-10-15 19:01 --- Subject: Re: g++ should emit different debug info for variable's type On Tue, Sep 23, 2008 at 08:48:32PM -, tromey at gcc dot gnu dot org wrote: > Jan> Tom, could you elaborate why x1 and x2 should be printed differently? > Jan> I do not say they should not but I do not see a clear reason for either > way. > > My view is that "whatis" should print the declared type, as much as possible. > Note that this is a contrived example. Here, it hardly matters. However, > there are many cases where "whatis" shows something incomprehensible > to the user. FYI, I don't think this is a good example of where GCC should do better. If you give different types for all source representations of the type, you'll sometimes need full versions of the class and all its methods for each of the alternate spellings; wasteful and confusing to the debugger. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37590
[Bug fortran/37833] internal compiler error: in gfc_conv_function_call, at fortran/trans-expr.c:1108
--- Comment #9 from burnus at gcc dot gnu dot org 2008-10-15 09:22 --- Thanks for the bugreport, however, it works here with GCC 4.4, 4.3, 4.2 and 4.1. Your GCC -- "gcc version 4.0.3" -- is ancient. GCC 4.0 was branched on Feb 25 2005 while some fixes still went into the 4.0 branch, most work went into GCC 4.1 which was then branched on Nov 18 2005, which is also already 3 years ago. GCC 4.0 was the first GCC version which shipped gfortran and gfortran had lots of bugs back then. GCC 4.1.x is the oldest GCC one should use for gfortran. However, gfortran 4.2 and 4.3 are much stabler. I would suggest to update to 4.3.2 (latest stable release) or to 4.4.0 (latest developer release). If needed be 4.2.x and maybe also 4.1.x can be used, but 4.0 is definitely too buggy. Nightly builds of gfortran are available at: http://gcc.gnu.org/wiki/GFortranBinaries -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37833
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #15 from jakub at gcc dot gnu dot org 2008-10-15 09:17 --- FYI, if you compile with -O1 -ffast-math -fsigned-zeros, then it works correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug libfortran/37839] New: st_parameter_dt has unwanted padding, is out of sync with compiler
On systems where GFC_IO_INT is 8 bytes and requires 8 byte alignment the st_parameter_dt structure may be out of sync between the fortran library and compiler because the common field of st_parameter_dt is 28 bytes long (if pointers and ints are 4 bytes each) and the next field (rec) is of type GFC_IO_INT which is 8 bytes if 8 byte ints are supported. The padding between common and rec is not accounted for in the compiler when accessing the structure. On ia64-*-hpux* this cause gfortran.dg/f2003_io_[14567].f03 to fail in 32 bit mode. -- Summary: st_parameter_dt has unwanted padding, is out of sync with compiler Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sje at cup dot hp dot com GCC target triplet: ia64-*-hpux* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37839
[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always
--- Comment #6 from dodji at gcc dot gnu dot org 2008-10-15 19:36 --- @jason: Thanks for you comment. I am adding Mark in CC to the bug so that we can close the bug in WONTFIX eventually, it you both agree :-) -- dodji at gcc dot gnu dot org changed: What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429
[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always
--- Comment #7 from mmitchel at gcc dot gnu dot org 2008-10-15 20:20 --- The comment in the test says: /* Make sure we didn't eliminate casted types because we thought they were unused. */ If we don't want to do that any more, I think we can just remove this test, rather than passing it special options. But, I think it's odd if I'm in the debugger, looking at code that says: return (X*)y; if I can't say "print (X*)y". If the type is coming from a library, we may not ever create objects of this type. Finally, we use vast amounts of space in object files for debug info, since we emit the same debug info in multiple object files. Trying to optimize by not emitting debug info in this case doesn't seem likely to be a big win given our overall strategy. I don't have any data to support that claim, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429
[Bug c/37106] [4.4 Regression] ICE with -fpic or -fPIC: in mems_in_disjoint_alias_sets_p, at alias.c:278
--- Comment #16 from hjl dot tools at gmail dot com 2008-10-15 21:06 --- (In reply to comment #13) > Sorry no. I see that some postings have the revision number in the postiong > subject, but I don't know how to do that nor why everyone isn't having that > done by default. It would have been useful in retrospect. :-/ > If you use "contrib/gcc_update" to update your SVN tree, "gcc --version" will report 4.4.0 20081015 (experimental) [trunk revision 141140] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37106
[Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
--- Comment #7 from spop at gcc dot gnu dot org 2008-10-15 21:28 ---
split_constant_offset does not handle correctly the offset of
&s.c[1] as this is an ADDR_EXPR whose op0 was set by
extract_ops_from_tree to itself, an ADDR_EXPR. Now this code
is not handled in split_constant_offset_1 as this calls
if (!handled_component_p (op0))
return false;
and returns false. This is an early return that stops the extraction
of the base address of the array: s.c[0] and the offset 4.
This is probably due to the fact that extract_ops_from_tree does
return the expression itself for ADDR_EXPRs in this case:
else if (grhs_class == GIMPLE_SINGLE_RHS)
{
*op1_p = expr;
*op2_p = NULL_TREE;
}
I wonder if the fix could be to handle ADDR_EXPRs as GIMPLE_UNARY_RHS
instead of GIMPLE_SINGLE_RHS:
else if (grhs_class == GIMPLE_UNARY_RHS)
{
*op1_p = TREE_OPERAND (expr, 0);
*op2_p = NULL_TREE;
}
in which case that would solve the base and offset computations.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
--- Comment #9 from vincent at vinc17 dot org 2008-10-15 21:29 --- What was said in bug 37838 but not here is that -frounding-math sometimes fixes the problem. So, I was suggesting that -frounding-math should be enabled by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
[Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-10-15 21:45 --- No, ADDR_EXPRs are single because they can have an arbitrary number of operands (think of &a_1->b[i_2][j_3] which has three operands, a_1, i_2 and j_3). In your case it is a is_gimple_min_invariant, which may add to the confusion? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-10-15 21:47 ---
IMHO the fix for the tuplification bug(!) is to strip the ADDR_EXPR that is
always present on op0 in split_constant_offset_1 so:
case ADDR_EXPR:
{
tree base, poffset;
HOST_WIDE_INT pbitsize, pbitpos;
enum machine_mode pmode;
int punsignedp, pvolatilep;
op0 = TREE_OPERAND (op0, 0);
if (!handled_component_p (op0))
return false;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-10-15 22:14 --- The default of -fno-rounding-math is chosen with the reason that this is what a compiler can assume if #pragma STDC FENV_ACCESS is not turned on. What you may request instead is an implementation of FENV_ACCESS up to that point that we issue a fatal error whenever you try to turn it on. Or at least a warning by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always
--- Comment #8 from jason at redhat dot com 2008-10-15 22:23 --- Subject: Re: debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always mmitchel at gcc dot gnu dot org wrote: > /* Make sure we didn't eliminate casted types because we thought they were > >unused. */ Yes, my point was that the reason we omit the debug info in this case is not that we think the type is unused, it's that even though we know it is used, we expect it to be emitted elsewhere. > But, I think it's odd if I'm in the debugger, looking at code that says: > > return (X*)y; > > if I can't say "print (X*)y". > > If the type is coming from a library, we may not ever create objects of this > type. If the Xes are created in the library, the library should have the debug info we need. I can't imagine a use for a statement like that in a program that doesn't have a definition of the vtable for X. If no X has ever been created, then doing anything interesting with the X* will have undefined behavior, because it couldn't possibly point to an X. > Finally, we use vast amounts of space in object files for debug info, since we > emit the same debug info in multiple object files. Trying to optimize by not > emitting debug info in this case doesn't seem likely to be a big win given our > overall strategy. I don't have any data to support that claim, though. I'm not sure what overall strategy you mean. We try to avoid emitting the same info in multiple places when possible: we try to treat the debug info for classes as another vague linkage entity and put it with the vtable. Unfortunately, it isn't yet possible to use linkonce for debug info because of GDB limitations, so our opportunities for optimization are limited. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
--- Comment #11 from vincent at vinc17 dot org 2008-10-15 22:33 --- (In reply to comment #10) > The default of -fno-rounding-math is chosen with the reason that this is what > a compiler can assume if #pragma STDC FENV_ACCESS is not turned on. The C standard doesn't require a compiler to recognize the FENV_ACCESS pragma, but if the compiler does not recognize it, then it must assume that this pragma is ON (otherwise the generated code can be incorrect). That's why I suggested that -frounding-math should be the default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
[Bug target/37841] New: SPU compiler is not complaint with the ABI
Functions with more than 72 arguments, pass char/short arguments 73 and higher in the wrong position in the quadword stored on the stack. This is due to the char/short not being at offset 0 of the word (char/short are stored in the bottom of the first int in the quadword). -- Summary: SPU compiler is not complaint with the ABI Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gnu at the-meissners dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: spu-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37841
[Bug debug/33429] debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always
--- Comment #9 from mark at codesourcery dot com 2008-10-15 22:51 --- Subject: Re: debug info for class2 in g++.dg/other/unused1.C requires -femit-class-debug-always jason at redhat dot com wrote: >> But, I think it's odd if I'm in the debugger, looking at code that says: >> >> return (X*)y; >> >> if I can't say "print (X*)y". >> >> If the type is coming from a library, we may not ever create objects of this >> type. > > If the Xes are created in the library, the library should have the debug > info we need. That assumes a friendly library distributor. :-) The library is provided to us in binary form and stripped, and if it does have debug info it might not have come from GCC. But, if it's declared in a header, we can still provide debug info. >> Finally, we use vast amounts of space in object files for debug info, since >> we >> emit the same debug info in multiple object files. Trying to optimize by not >> emitting debug info in this case doesn't seem likely to be a big win given >> our >> overall strategy. I don't have any data to support that claim, though. > > I'm not sure what overall strategy you mean. We try to avoid emitting > the same info in multiple places when possible: we try to treat the > debug info for classes as another vague linkage entity and put it with > the vtable. OK, my statement was overly strong. I was thinking particularly of C++ templates, where the vague linkage strategy makes for lots of copies, both in the object files, and, because we don't use COMDAT, in the final binaries. In that kind of C++ code, this optimization doesn't save a significant percentage of space. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429
[Bug libfortran/37839] st_parameter_dt has unwanted padding, is out of sync with compiler
--- Comment #1 from janis at gcc dot gnu dot org 2008-10-15 23:09 --- The tests listed in the submitter's description also fail (according to archived testresults) on powerpc-unknown-linux-gnu, hppa-unknown-linux-gnu, and powerpc-ibm-aix5.3.0.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37839
[Bug fortran/37842] New: f2003_io_[1-7].f03 execute test fails
FAIL: gfortran.dg/f2003_io_1.f03 -O0 execution test FAIL: gfortran.dg/f2003_io_1.f03 -O1 execution test FAIL: gfortran.dg/f2003_io_1.f03 -O2 execution test FAIL: gfortran.dg/f2003_io_1.f03 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/f2003_io_1.f03 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/f2003_io_1.f03 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/f2003_io_1.f03 -O3 -g execution test FAIL: gfortran.dg/f2003_io_1.f03 -Os execution test FAIL: gfortran.dg/f2003_io_4.f03 -O0 execution test FAIL: gfortran.dg/f2003_io_4.f03 -O1 execution test FAIL: gfortran.dg/f2003_io_4.f03 -O2 execution test FAIL: gfortran.dg/f2003_io_4.f03 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/f2003_io_4.f03 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/f2003_io_4.f03 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/f2003_io_4.f03 -O3 -g execution test FAIL: gfortran.dg/f2003_io_4.f03 -Os execution test FAIL: gfortran.dg/f2003_io_5.f03 -O0 execution test FAIL: gfortran.dg/f2003_io_5.f03 -O1 execution test FAIL: gfortran.dg/f2003_io_5.f03 -O2 execution test FAIL: gfortran.dg/f2003_io_5.f03 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/f2003_io_5.f03 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/f2003_io_5.f03 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/f2003_io_5.f03 -O3 -g execution test FAIL: gfortran.dg/f2003_io_5.f03 -Os execution test FAIL: gfortran.dg/f2003_io_6.f03 -O0 execution test FAIL: gfortran.dg/f2003_io_6.f03 -O1 execution test FAIL: gfortran.dg/f2003_io_6.f03 -O2 execution test FAIL: gfortran.dg/f2003_io_6.f03 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/f2003_io_6.f03 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/f2003_io_6.f03 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/f2003_io_6.f03 -O3 -g execution test FAIL: gfortran.dg/f2003_io_6.f03 -Os execution test FAIL: gfortran.dg/f2003_io_7.f03 -O0 execution test FAIL: gfortran.dg/f2003_io_7.f03 -O1 execution test FAIL: gfortran.dg/f2003_io_7.f03 -O2 execution test FAIL: gfortran.dg/f2003_io_7.f03 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/f2003_io_7.f03 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/f2003_io_7.f03 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/f2003_io_7.f03 -O3 -g execution test FAIL: gfortran.dg/f2003_io_7.f03 -Os execution test These tests also fail as of 20081015 on powerps64-suse-linux-gnu. -- Summary: f2003_io_[1-7].f03 execute test fails Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-* (32-bit) GCC host triplet: hppa*-*-* (32-bit) GCC target triplet: hppa*-*-* (32-bit) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37842
[Bug target/37633] [4.4 Regression] wrong register use on sh64
--- Comment #5 from kkojima at gcc dot gnu dot org 2008-10-15 23:14 --- Thanks for taking a look at this problem. Your patch mentioned in #3 fixes the test case in #1 on sh64. Even with it, there are similar failures with -O0 in the result of the gcc testsuite on sh64-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37633
[Bug fortran/37842] f2003_io_[1-7].f03 execute test fails
--- Comment #1 from danglin at gcc dot gnu dot org 2008-10-15 23:17 --- Executing on host: /home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran -B/home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran/../../ /home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/f2003_io_1.f03 -O0 -std=gnu -L/home/dave/gnu/gcc/objdir/hppa-linux/./libgfortran/.libs -L/home/dave/gnu/gcc/objdir/hppa-linux/./libgfortran/.libs -L/home/dave/gnu/gcc/objdir/hppa-linux/./libiberty -lm -o ./f2003_io_1.exe (timeout = 300) PASS: gfortran.dg/f2003_io_1.f03 -O0 (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/dave/gnu/gcc/objdir/hppa-linux/./libgfortran/.libs:/home/dave/gnu/gcc/objdir/hppa-linux/./libgfortran/.libs:/home/dave/gnu/gcc/objdir/gcc:.:/home/dave/gnu/gcc/objdir/hppa-linux/./libgfortran/.libs:/home/dave/gnu/gcc/objdir/hppa-linux/./libgfortran/.libs:/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/.libs:/home/dave/gnu/gcc/objdir/hppa-linux/libmudflap/.libs:/home/dave/gnu/gcc/objdir/hppa-linux/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux/libgomp/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc At line 13 of file /home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/f2003_io_1.f03 (unit = 10, file = 'mydata') Fortran runtime error: Bad DECIMAL parameter in data transfer statement FAIL: gfortran.dg/f2003_io_1.f03 -O0 execution test -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37842
[Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
--- Comment #10 from spop at gcc dot gnu dot org 2008-10-16 00:02 ---
Subject: Re: [4.4 Regression] gcc-4.4 regression: incorrect code generation
with -O1 -ftree-vectorize
On Wed, Oct 15, 2008 at 4:47 PM, rguenth at gcc dot gnu dot org
> IMHO the fix for the tuplification bug(!) is to strip the ADDR_EXPR that is
> always present on op0 in split_constant_offset_1 so:
>
>case ADDR_EXPR:
> {
>tree base, poffset;
>HOST_WIDE_INT pbitsize, pbitpos;
>enum machine_mode pmode;
>int punsignedp, pvolatilep;
>
>op0 = TREE_OPERAND (op0, 0);
>if (!handled_component_p (op0))
> return false;
This is exactly what I tried within gdb and it did worked, although
not as I expected: the base address ends to be &s and not &s.c[0] as
I expected before. This then fixes the bug as we end on the same
base address of the structure. Then the alias analysis answers that
the two accesses can overlap.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug middle-end/37674] [4.4 Regression] Bootstrap failure due to miscompilation of genattrtab
--- Comment #7 from vmakarov at gcc dot gnu dot org 2008-10-16 00:23 --- Subject: Bug 37674 Author: vmakarov Date: Thu Oct 16 00:22:13 2008 New Revision: 141159 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141159 Log: 2008-10-15 Vladimir Makarov <[EMAIL PROTECTED]> PR middle-end/37674 * ira-build.c (ira_flattening): Recalculate ALLOCNO_TOTAL_NO_STACK_REG_P and ALLOCNO_TOTAL_CONFLICT_HARD_REGS from the scratch instead of the propagation. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-build.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37674
[Bug target/37843] New: [4.4 Regression] unaligned stack in main due to tail call optimization
[EMAIL PROTECTED] 880]$ cat x.c
extern int foo ();
int main()
{
return foo();
}
[EMAIL PROTECTED] 880]$ rm x.s
[EMAIL PROTECTED] 880]$ cat x.c
extern int foo ();
int main()
{
return foo();
}
[EMAIL PROTECTED] 880]$ make
/export/gnu/import/svn/gcc-test/bld/gcc/xgcc
-B/export/gnu/import/svn/gcc-test/bld/gcc/ -O2 -m32 -S -o x.s x.c
[EMAIL PROTECTED] 880]$ cat x.s
.file "x.c"
.text
.p2align 4,,15
.globl main
.type main, @function
main:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
leave
jmp foo
The stack isn't aligned to 16byte.
.size main, .-main
--
Summary: [4.4 Regression] unaligned stack in main due to tail
call optimization
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
GCC target triplet: i686-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37843
[Bug middle-end/37535] [4.4 Regression] gcc/libgcc2.c:404: internal compiler error: Floating point exception
--- Comment #19 from vmakarov at gcc dot gnu dot org 2008-10-16 00:53 --- Subject: Bug 37535 Author: vmakarov Date: Thu Oct 16 00:51:34 2008 New Revision: 141160 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141160 Log: 2008-10-15 Vladimir Makarov <[EMAIL PROTECTED]> PR middle-end/37535 * ira-lives.c (mark_early_clobbers): Remove. (make_pseudo_conflict, check_and_make_def_use_conflicts, check_and_make_def_conflicts, make_early_clobber_and_input_conflicts, mark_hard_reg_early_clobbers): New functions. (process_bb_node_lives): Call make_early_clobber_and_input_conflicts and mark_hard_reg_early_clobbers. Make hard register inputs live again. * doc/rtl.texi (clobber): Change descriotion of RA behaviour for early clobbers of pseudo-registers. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/rtl.texi trunk/gcc/ira-lives.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37535
[Bug target/37633] [4.4 Regression] wrong register use on sh64
--- Comment #6 from vmakarov at gcc dot gnu dot org 2008-10-16 00:54 --- Subject: Bug 37633 Author: vmakarov Date: Thu Oct 16 00:52:59 2008 New Revision: 141161 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141161 Log: 2008-10-14 Vladimir Makarov <[EMAIL PROTECTED]> PR target/37633 * ira-costs.c (ira_tune_allocno_costs_and_cover_classes): Check HARD_REGNO_CALL_PART_CLOBBERED. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-costs.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37633
[Bug target/37843] [4.4 Regression] unaligned stack in main due to tail call optimization
--- Comment #1 from hjl dot tools at gmail dot com 2008-10-16 01:06 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00670.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||10/msg00670.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37843
[Bug tree-optimization/37705] [graphite] Fix problems with SCoPs, that contain more than one loop
--- Comment #1 from grosser at gcc dot gnu dot org 2008-10-16 05:20 --- Created an attachment (id=16505) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16505&action=view) Fix loop_affine_expr to remove limit_scops () - This is a HACK looking for smarter solution Problem 1: Scalar evolution functions in loop limits and conditions have to be constant or affine to be allowed in a SCoP. During SCoP detection we check this with: if (evolution_function_is_invariant_p (scev, n) || evolution_function_is_affine_multivariate_p (scev, n)); in loop_affine_expr(). If this expression is true, it is allowed in a SCoP. But e.g. the constant expr "p_1 * p_2" is allow in a SCoP, but we can not represent it using the polyhedron model. The matrix would be p_1 p_2 Const xyz with x*p_1 + y*p_2 + z There is no way to represent p_1 * p_2, so we fail in scan_tree_for_params trying to generate the matrix. There are two solutions: 1. This expression is representable, if we introduce a new parameter p_3 = p_1 * p_2 and calculate it before the SCoP. 2. We detect this cases and do not allow them in any SCoP. I would like to start with solution two. Later on we can implement solution one. I attached a patch, that simply copies scan_tree_for_params() and returns true, if a expression can be handled by scan_tree_for_params() otherwise false. This works on polyhedron using -fgraphite, but seems not to be the cleanest solution. I would prefer to keep if (evolution_function_is_invariant_p (scev, n) || evolution_function_is_affine_multivariate_p (scev, n)); and add only && (no_multiplication_in_parameters (scev)). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37705
[Bug tree-optimization/37705] [graphite] Remove limit_scops() workaround
-- grosser at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2008-10-01 17:16:46 |2008-10-16 05:33:30 date|| Summary|[graphite] Remove |[graphite] Remove |limit_scops workaround |limit_scops() workaround http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37705
[Bug middle-end/37844] New: -floop-interchange leads to an ICE
$gcc --version gcc (GCC) 4.4.0 20081015 (experimental) $gcc -c -O3 -floop-interchange cp-demangle.c /svn/gcc/libiberty/cp-demangle.c: In function 'd_find_pack': /svn/gcc/libiberty/cp-demangle.c:3164: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. -- Summary: -floop-interchange leads to an ICE Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: linuxl4 at sohu 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=37844
[Bug middle-end/37844] -floop-interchange leads to an ICE
--- Comment #1 from linuxl4 at sohu dot com 2008-10-16 06:37 --- Created an attachment (id=16506) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16506&action=view) the preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37844
[Bug tree-optimization/37525] [4.4 Regression] IVOPTS difference causing 20% degradation in 173.applu benchmark
--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-16 06:51 --- Subject: Bug 37525 Author: jakub Date: Thu Oct 16 06:50:30 2008 New Revision: 141164 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141164 Log: PR tree-optimization/37525 * tree.c (int_fits_type_p): Rewrite using double_int. Zero extend sizetype unsigned constants, both in the case of C and bounds. Modified: trunk/gcc/ChangeLog trunk/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37525
