[Bug tree-optimization/33402] FAIL: gcc.dg/tree-ssa/loadpre11.c scan-tree-dump-times Eliminated: 1 1
--- Comment #4 from ubizjak at gmail dot com 2007-09-12 06:50 --- Fixed by http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00364.html -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33402
[Bug target/33369] [4.3 Regression] suffix or operands invalid for `pslld'
--- Comment #6 from ubizjak at gmail dot com 2007-09-12 06:52 --- Middle-end was fixed by http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00406.html -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33369
[Bug target/33393] floatsisf2_sse_vector_nointernunit doesn't work on 32bit
--- Comment #1 from hubicka at gcc dot gnu dot org 2007-09-12 07:03 --- Subject: Bug 33393 Author: hubicka Date: Wed Sep 12 07:02:31 2007 New Revision: 128414 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128414 Log: PR target/33393 * i386.md (floatsisf2_mixed_memory, floatsisf2_sse_memory): Disable for !SSE_MATH Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33393
[Bug tree-optimization/33373] ICE in vectorizable_type_demotion, at tree-vect-transform.c:4098
--- Comment #3 from dorit at gcc dot gnu dot org 2007-09-12 07:10 --- Subject: Bug 33373 Author: dorit Date: Wed Sep 12 07:09:38 2007 New Revision: 128415 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128415 Log: PR tree-optimization/33373 * tree-vect-analyze (vect_determine_vectorization_factor): Call TREE_INT_CST_LOW when comparing TYPE_SIZE_UNIT. Added: trunk/gcc/testsuite/gcc.dg/vect/pr33373.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-analyze.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33373
[Bug target/32895] Clobber list isn't working
--- Comment #1 from wvangulik at xs4all dot nl 2007-09-12 07:20 ---
Tested this against 4.1.2. The output for the given test case is different
(optimiser removed the useless loading):
/* prologue: frame size=0 */
push r28
/* prologue end (size=1) */
/* #APP */
in r28, 0x2F
/* #NOAPP */
/* epilogue: frame size=0 */
pop r28
ret
However making the struct volatile (there for forcing it on stack and thus
using Y pointer) generates the requested error:
void test(void)
{
volatile struct
{
int a, b, c, d, e, f;
} x;
x.d = 5;
asm volatile(in r28, 0x2F : : : r28);
x.d = 6;
}
Gives this error
test.c: In function 'test':
test.c:11: error: r28 cannot be used in asm here
--
Using gcc version:
Using built-in specs.
Target: avr
Configured with: ../gcc-4.1.2/configure --prefix=/c/WinAVR --target=avr
--enable
-languages=c,c++ --with-dwarf2 --enable-win32-registry=WinAVR-20070525
--disable
-nls --with-gmp=/usr/local --with-mpfr=/usr/local --enable-doc --disable-libssp
Thread model: single
gcc version 4.1.2 (WinAVR 20070525)
---
So could it's know to work for 4.1.2. I can't test this against a higher
version at the moment.
--
wvangulik at xs4all dot nl changed:
What|Removed |Added
CC||wvangulik at xs4all dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32895
[Bug target/32895] Clobber list isn't working
--- Comment #2 from wvangulik at xs4all dot nl 2007-09-12 07:32 --- (In reply to comment #1) Hmm I cheated... I used -Os when compiling Compiling without -O[n] gives no warning Just tried compiling -O and then it does generate the error. It seems optimiser flags triggers the warning? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32895
[Bug target/32895] Clobber list isn't working
--- Comment #3 from wvangulik at xs4all dot nl 2007-09-12 07:35 --- (In reply to comment #2) Ok I need some coffee... The error IS generated when using -O[n] (so on -O as well) Without specifing -O the compiler does not generate the warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32895
[Bug middle-end/33382] [4.2 Regression] internal compiler error: in get_constraint_for_component_ref, at tree-ssa-structalias.c:2454
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-09-12 07:54 --- Subject: Bug 33382 Author: rguenth Date: Wed Sep 12 07:54:17 2007 New Revision: 128417 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128417 Log: 2007-09-12 Richard Guenther [EMAIL PROTECTED] PR middle-end/33382 * tree-ssa-structalias.c (get_constraint_for_component_ref): Note that accesses to a whole flexible array member may not lead to a subvariable. * gcc.c-torture/compile/pr33382.c: New testcase. * gcc.c-torture/execute/pr33382.c: Likewise. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/compile/pr33382.c branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/pr33382.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33382
[Bug fortran/33395] [ISO_C_BINDING ?] ICE (segfault) in gfc_conv_initializer
--- Comment #6 from burnus at gcc dot gnu dot org 2007-09-12 07:56 --- Subject: Bug 33395 Author: burnus Date: Wed Sep 12 07:56:07 2007 New Revision: 128418 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128418 Log: 2007-09-12 Christopher D. Rickett [EMAIL PROTECTED] PR fortran/33395 * trans-expr.c (gfc_conv_initializer): Remove unnecessary test for intmod_sym_id and use derived symbol to set new kind of C_NULL_PTR and C_NULL_FUNPTR expressions. 2007-09-12 Christopher D. Rickett [EMAIL PROTECTED] PR fortran/33395 * gfortran.dg/c_ptr_tests_12.f03: New test case. Added: trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_12.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33395
[Bug middle-end/33382] [4.2 Regression] internal compiler error: in get_constraint_for_component_ref, at tree-ssa-structalias.c:2454
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-09-12 08:07 --- Subject: Bug 33382 Author: rguenth Date: Wed Sep 12 08:07:12 2007 New Revision: 128419 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128419 Log: 2007-09-12 Richard Guenther [EMAIL PROTECTED] PR middle-end/33382 * gcc.c-torture/compile/pr33382.c: New testcase. * gcc.c-torture/execute/pr33382.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr33382.c - copied unchanged from r128417, branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/compile/pr33382.c trunk/gcc/testsuite/gcc.c-torture/execute/pr33382.c - copied unchanged from r128417, branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/pr33382.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33382
[Bug fortran/33395] [ISO_C_BINDING ?] ICE (segfault) in gfc_conv_initializer
--- Comment #7 from burnus at gcc dot gnu dot org 2007-09-12 08:19 --- FIXED. (The FGSL test suite still fails due to the broken formatted read of a line ending without line break, see PR 33400; working around that bug, the test suite succeeds - hooray!) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33395
[Bug middle-end/33382] [4.2 Regression] internal compiler error: in get_constraint_for_component_ref, at tree-ssa-structalias.c:2454
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-09-12 08:27 --- 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=33382
[Bug c++/33401] Unwanted memset in default constructor
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-12 08:33 --- So, invalid. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33401
[Bug tree-optimization/33404] New: Predictive commoning + ivopts possibly introducing extra sign extensions.
Hi ,
There's a difference in the code generated between O2 and O3 in the case below.
void fred(long in, short *out1)
{
int i;
for (i=0;i100;i++)
out1[i+1] = out1[i]*in;
}
With O2 we generate at expand time -
fred (in, out1)
{
unsigned int ivtmp.24;
bb 2:
ivtmp.24 = (unsigned int) out1;
bb 3:
MEM[index: ivtmp.24, offset: 2] = (short int) (in * (long int) MEM[index:
ivtmp.24]);
ivtmp.24 = ivtmp.24 + 2;
if (ivtmp.24 != (unsigned int) (out1 + 200))
goto bb 3;
else
goto bb 4;
bb 4:
return;
}
With O3 we generate .
fred (in, out1)
{
unsigned int ivtmp.23;
short int D__lsm0.18;
long int D.1212;
bb 2:
D__lsm0.18 = *out1;
ivtmp.23 = 1;
bb 3:
D.1212 = (long int) D__lsm0.18 * in;
D__lsm0.18 = (short int) D.1212;
MEM[base: out1, index: ivtmp.23 * 2] = D__lsm0.18;
ivtmp.23 = ivtmp.23 + 1;
if (ivtmp.23 != 101)
goto bb 3;
else
goto bb 4;
bb 4:
return;
}
--
Summary: Predictive commoning + ivopts possibly introducing extra
sign extensions.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana dot radhakrishnan at celunite dot com
GCC build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33404
[Bug c++/33405] New: [ICE] final_scan_insn, at final.c:2117
I cannot compile the following file: $ /usr/bin/g++-3.3 -save-temps -D_IntensityFiltersPython_EXPORTS -g -Wall -W -Woverloaded-virtual -Wunused -ftemplate-depth-50 -w -ftemplate-depth-50 -O3 -DNDEBUG -fPIC -I/home/mmalaterre/Projects/Insight/Code/Review -I/home/mmalaterre/Projects/Insight/Utilities/gdcm/src -I/home/mmalaterre/Projects/Insight-gcc/Utilities/gdcm -I/home/mmalaterre/Projects/Insight-gcc/Utilities/vxl/core -I/home/mmalaterre/Projects/Insight-gcc/Utilities/vxl/vcl -I/home/mmalaterre/Projects/Insight/Utilities/vxl/core -I/home/mmalaterre/Projects/Insight/Utilities/vxl/vcl -I/home/mmalaterre/Projects/Insight-gcc/Code/Common -I/home/mmalaterre/Projects/Insight/Utilities -I/home/mmalaterre/Projects/Insight-gcc/Utilities -I/home/mmalaterre/Projects/Insight/Utilities/itkExtHdrs -I/home/mmalaterre/Projects/Insight/Utilities/nifti/znzlib -I/home/mmalaterre/Projects/Insight/Utilities/nifti/niftilib -I/home/mmalaterre/Projects/Insight/Utilities/expat -I/home/mmalaterre/Projects/Insight-gcc/Utilities/expat -I/home/mmalaterre/Projects/Insight-gcc/Utilities/DICOMParser -I/home/mmalaterre/Projects/Insight/Utilities/DICOMParser -I/home/mmalaterre/Projects/Insight/Utilities/NrrdIO -I/home/mmalaterre/Projects/Insight/Utilities/MetaIO -I/home/mmalaterre/Projects/Insight/Code/SpatialObject -I/home/mmalaterre/Projects/Insight/Code/Numerics/NeuralNetworks -I/home/mmalaterre/Projects/Insight/Code/Numerics/Statistics -I/home/mmalaterre/Projects/Insight/Code/Numerics/FEM -I/home/mmalaterre/Projects/Insight/Code/IO -I/home/mmalaterre/Projects/Insight/Code/Numerics -I/home/mmalaterre/Projects/Insight/Code/Common -I/home/mmalaterre/Projects/Insight/Code/BasicFilters -I/home/mmalaterre/Projects/Insight/Code/Algorithms -I/home/mmalaterre/Projects/Insight-gcc -I/home/mmalaterre/Projects/Insight/Utilities/vxl/v3p/netlib -I/usr/include/python2.3 -I/home/mmalaterre/Projects/Insight/Wrapping/WrapITK/Modules/IntensityFilters -DSWIG_GLOBAL -o Wrapping/WrapITK/Modules/IntensityFilters/CMakeFiles/_IntensityFiltersPython.dir/wrap_itkRescaleIntensityImageFilterPython.o -c /home/mmalaterre/Projects/Insight-gcc/Wrapping/WrapITK/Modules/IntensityFilters/wrap_itkRescaleIntensityImageFilterPython.cxx /home/mmalaterre/Projects/Insight-gcc/Wrapping/WrapITK/Modules/IntensityFilters/wrap_itkRescaleIntensityImageFilterPython.cxx: In function `PyObject* _wrap_itkRescaleIntensityImageFilterID4IUS4_Pointer_GetPointer(PyObject*, PyObject*)': /home/mmalaterre/Projects/Insight-gcc/Wrapping/WrapITK/Modules/IntensityFilters/wrap_itkRescaleIntensityImageFilterPython.cxx:524307: internal compiler error: in final_scan_insn, at final.c:2117 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-3.3/README.Bugs. Version: $ /usr/bin/g++-3.3 --version g++-3.3 (GCC) 3.3.6 (Debian 1:3.3.6-15) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Summary: [ICE] final_scan_insn, at final.c:2117 Product: gcc Version: 3.3.6 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mathieu dot malaterre at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33405
[Bug bootstrap/33406] New: At revision 128385 Bootstraping PPC Darwin still fail in Java
The bootstrap failure reported in http://gcc.gnu.org/ml/gcc/2007-09/msg00147.html is still present in revision 128385. -- Summary: At revision 128385 Bootstraping PPC Darwin still fail in Java Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: powerpc-apple-darwin8 GCC host triplet: powerpc-apple-darwin8 GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33406
[Bug c++/33405] [ICE] final_scan_insn, at final.c:2117
--- Comment #1 from mathieu dot malaterre at gmail dot com 2007-09-12 09:05 --- sorry just found out: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711#c17 *** This bug has been marked as a duplicate of 14711 *** -- mathieu dot malaterre at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33405
[Bug middle-end/14711] [3.3/3.4 regression] ICE in final.c:2117 when compiling a huge source file
--- Comment #27 from mathieu dot malaterre at gmail dot com 2007-09-12 09:05 --- *** Bug 33405 has been marked as a duplicate of this bug. *** -- mathieu dot malaterre at gmail dot com changed: What|Removed |Added CC||mathieu dot malaterre at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14711
[Bug c++/33403] warning: missing sentinel in function call for 0 rather than NULL
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-09-12 09:18 --- (In reply to comment #2) I don't know about most likely. sizeof(int) == sizeof(void*) is still pretty common, so my guess would be that the warning is more often wrong than not. Common on ILP32 targets but since this was reported for LP64 target anyways, what is the difference. Remember sizeof(int) might be equal to sizeof(void*) on most targets but it does not have to. In fact this warning is for portability reasons (though in this case is also correctness). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33403
[Bug fortran/33310] Bind(C): Accepts PARAMETER with BIND(C) attribute
--- Comment #2 from patchapp at dberlin dot org 2007-09-12 09:20 --- Subject: Bug number PR33310 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-09/msg00333.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33310
[Bug bootstrap/33406] At revision 128385 Bootstraping PPC Darwin still fail in Java
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-12 09:34 --- libgomp is also broken for powerpc*-linux-gnu. It times out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33406
[Bug c++/33407] New: C++ operator new and new expression do not change dynamic type
Nothing in the IL of the following testcase prevents the stores
to *q and *r in function doit from being reordered:
extern C void * malloc(__SIZE_TYPE__);
extern C void abort(void);
void *p;
void __attribute__((noinline)) init(void)
{
p = malloc(4);
}
inline void *operator new(__SIZE_TYPE__)
{
return p;
}
inline void operator delete (void*) {}
int * __attribute__((noinline)) doit(void)
{
float *q = new float;
*q = 1.0;
delete q;
int *r = new int;
*r = 1;
return r;
}
int main()
{
if (*doit() != 1)
abort();
return 0;
}
from the first alias run results:
int* doit() ()
{
void * D.1643;
void * D.1643;
void * D.1639;
void * D.1639;
int * r;
float * q;
bb 2:
# VUSE p_14(D)
D.1639_7 = p;
q_2 = (float *) D.1639_7;
# SMT.6_16 = VDEF SMT.6_15(D)
*q_2 = 1.0e+0;
# VUSE p_14(D)
D.1643_8 = p;
r_4 = (int *) D.1643_8;
# SMT.7_18 = VDEF SMT.7_17(D)
*r_4 = 1;
return r_4;
}
One way to fix this is to make sure that if operator new is inlined
we insert a CHANGE_DYNAMIC_TYPE_EXPR.
--
Summary: C++ operator new and new expression do not change
dynamic type
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code, alias
Severity: normal
Priority: P3
Component: c++
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=33407
[Bug c++/33407] C++ operator new and new expression do not change dynamic type
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-09-12 10:00 --- Related to PR29286. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||29286 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33407
[Bug c++/33407] C++ operator new and new expression do not change dynamic type
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-09-12 10:13 ---
main should call init(), but it doesn't make a difference for the IL. The
bug is wrong-IL for me only at the moment, but nothing prevents the two stores
from being reordered.
Here's one that abort()s at runtime on i686 with -O2 for me: (same trick
as in PR29286, trick LIM into reordering the stores :))
extern C void * malloc(__SIZE_TYPE__);
extern C void abort(void);
void *p;
void __attribute__((noinline)) init(void)
{
p = malloc(4);
}
inline void *operator new(__SIZE_TYPE__)
{
return p;
}
inline void operator delete (void*) {}
int * __attribute__((noinline)) doit(int n)
{
float *q;
int *r;
for (int i=0; in; ++i)
{
q = new float;
*q = 1.0;
delete q;
r = new int;
*r = 1;
}
return r;
}
int main()
{
init();
if (*doit(1) != 1)
abort();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33407
[Bug c++/33407] [4.1/4.3 Regression] C++ operator new and new expression do not change dynamic type
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-09-12 10:18 --- 4.2 works by luck as we weakened aliasing by the NONLOCAL stuff. 2.95 works for whatever reason ;) Even pre-tree-ssa we fail with -O2 (but it works with -O). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||3.3.6 3.4.6 4.0.4 4.1.2 ||4.3.0 Known to work||2.95.4 4.2.1 Summary|C++ operator new and new|[4.1/4.3 Regression] C++ |expression do not change|operator new and new |dynamic type|expression do not change ||dynamic type Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33407
[Bug c++/33407] [4.1/4.3 Regression] C++ operator new and new expression do not change dynamic type
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-12 10:20 --- -O fails with -fstrict-aliasing as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33407
[Bug fortran/33284] ENTRY and INTRINSIC with same name
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-12 10:27 --- Subject: Bug 33284 Author: burnus Date: Wed Sep 12 10:27:27 2007 New Revision: 128423 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128423 Log: 2007-09-12 Tobias Burnus [EMAIL PROTECTED] PR fortran/33284 PR fortran/33310 * symbol.c (check_conflict): Add conflict between INTRINSIC and ENTRY and between BIND(C) and PARAMETER. 2007-09-12 Tobias Burnus [EMAIL PROTECTED] PR fortran/33284 PR fortran/33310 * gfortran.dg/conflicts_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/conflicts_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33284
[Bug fortran/33310] Bind(C): Accepts PARAMETER with BIND(C) attribute
--- Comment #3 from burnus at gcc dot gnu dot org 2007-09-12 10:27 --- Subject: Bug 33310 Author: burnus Date: Wed Sep 12 10:27:27 2007 New Revision: 128423 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128423 Log: 2007-09-12 Tobias Burnus [EMAIL PROTECTED] PR fortran/33284 PR fortran/33310 * symbol.c (check_conflict): Add conflict between INTRINSIC and ENTRY and between BIND(C) and PARAMETER. 2007-09-12 Tobias Burnus [EMAIL PROTECTED] PR fortran/33284 PR fortran/33310 * gfortran.dg/conflicts_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/conflicts_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33310
[Bug fortran/33297] SIZE intrinsic crashes gfortran on invalid usage
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-12 10:30 --- Subject: Bug 33297 Author: burnus Date: Wed Sep 12 10:30:22 2007 New Revision: 128424 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128424 Log: 2007-09-12 Tobias Burnus [EMAIL PROTECTED] PR fortran/33297 * check.c (scalar_check): Move up in the file. (kind_check): Call scalar_check. (dim_check): If optional, do not call nonoptional_check; use bool for optional. (gfc_check_all_any,gfc_check_count,gfc_check_cshift,gfc_check_eoshift, gfc_check_lbound,gfc_check_minloc_maxloc,check_reduction, gfc_check_spread,gfc_check_ubound): Use true/false instead of 0/1 for dim_check; honor changed meaning of optional. (gfc_check_int): Replace checks by kind_check. (gfc_check_size): Replace checks by dim_check. 2007-09-12 Tobias Burnus [EMAIL PROTECTED] PR fortran/33297 * gfortran.dg/intrinsic_size.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/intrinsic_size.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33297
[Bug fortran/33297] SIZE intrinsic crashes gfortran on invalid usage
--- Comment #5 from burnus at gcc dot gnu dot org 2007-09-12 10:34 --- FIXED for the trunk (GCC gfortran 4.3.0). Thanks for the report. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33297
[Bug fortran/33310] Bind(C): Accepts PARAMETER with BIND(C) attribute
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-12 10:35 --- FIXED. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33310
[Bug fortran/33310] Bind(C): Accepts PARAMETER with BIND(C) attribute
--- Comment #5 from burnus at gcc dot gnu dot org 2007-09-12 10:36 --- Really mark as FIXED. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33310
[Bug fortran/33284] ENTRY and INTRINSIC with same name
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-12 10:36 --- FIXED. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33284
[Bug ada/15765] asmname should be verbatim if starting with an asterisk
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-09-12 11:45
---
I think this was fixed (from gcc/ada/gnat_ugn.texi):
@noindent
As for the @code{C} calling convention, when the @code{External_Name}
parameter is missing, it is taken to be the name of the Ada entity in lower
case. If instead of writing the above import pragma you write:
@smallexample @c ada
@group
function Get_Val (V : Interfaces.C.long) return Interfaces.C.int;
pragma Import (Stdcall, Get_Val, External_Name = retrieve_val);
@end group
@end smallexample
@noindent
then the imported routine is @code{_retrieve_val@@4}. However, if instead
of specifying the @code{External_Name} parameter you specify the
@code{Link_Name} as in the following example:
@smallexample @c ada
@group
function Get_Val (V : Interfaces.C.long) return Interfaces.C.int;
pragma Import (Stdcall, Get_Val, Link_Name = retrieve_val);
@end group
@end smallexample
@noindent
then the imported routine is @code{retrieve_val}, that is, there is no
decoration at all. No leading underscore and no Stdcall suffix
@code{@@[EMAIL PROTECTED]@i{nn}}.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |RESOLVED
Component|target |ada
Keywords|wrong-code |
Resolution||FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15765
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #2 from jh at suse dot cz 2007-09-12 12:01 --- Subject: Re: [4.3 Regression] Revision 128239 causes libgomp failure Hi, I´ve just tested ia64-linux and x86_64-linux on our testers and both are clean WRT libgomp: === libgomp Summary === # of expected passes496 it might be some sort of race condition (I sometimes see libgomp failures appear and go such as: libgomp.fortran/omp_parse3.f90 -O0 execution test One obvious difference is that we now consider functions produced by OMP lowering inlinable. This can be avoided by: Index: omp-low.c === *** omp-low.c (revision 128412) --- omp-low.c (working copy) *** expand_omp_parallel (struct omp_region * *** 2589,2594 --- 2589,2595 /* Inform the callgraph about the new function. */ DECL_STRUCT_FUNCTION (child_fn)-curr_properties = cfun-curr_properties; + DECL_UNINLINABLE (child_fn) = true; cgraph_add_new_function (child_fn, true); /* Fix the callgraph edges for child_cfun. Those for cfun will be I am not sure if the functions was uninlinable by decision or just because someone forgot to play with DECL_INLINE, but can you test this if it makes any difference? I can not think of any other difference this patch sould cause especially with -finline-functions. Jakub, is libgomp safe wrt inlining? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug c++/33401] Unwanted memset in default constructor
--- Comment #5 from kbateman at seicorp dot com 2007-09-12 12:52 --- Whaddaya know. Section 5-16, Expressions: If the new-initializer is of the form (), default-initialization shall be performed (8.5); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33401
[Bug target/29473] -masm=intel combined with -march=athlon64 has some issues.
--- Comment #9 from rask at gcc dot gnu dot org 2007-09-12 13:12 ---
This still happens with GCC 4.3 when trying to bootstrap with BOOT_CFLAGS='-O2
-g -fomit-frame-pointer -masm=intel' and it blocks me from working on bug
29493.
/home/rask/build/gcc-x86_64-unknown-linux-gnu/./prev-gcc/xgcc
-B/home/rask/build/gcc-x86_64-unknown-linux-gnu/./prev-gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/ -c -DHAVE_CONFIG_H -O2 -g
-fomit-frame-pointer -masm=intel -I. -I/home/rask/src/gcc/libiberty/../include
-W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic
/home/rask/src/gcc/libiberty/cplus-dem.c -o cplus-dem.o
/tmp/cc74KiHp.s: Assembler messages:
/tmp/cc74KiHp.s:818: Error: expecting string instruction after `rep'
make[3]: *** [cplus-dem.o] Error 1
make[3]: Leaving directory
`/home/rask/build/gcc-x86_64-unknown-linux-gnu/libiberty'
make[2]: *** [all-stage2-libiberty] Error 2
I have already found and fixed the cause of the other error message:
Error: invalid operand for 'movzx' ('(' unexpected)
It's caused by the ATT syntax (%rip) in the asm output.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||29493
nThis||
AssignedTo|unassigned at gcc dot gnu |rask at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Known to fail||4.3.0
Last reconfirmed|-00-00 00:00:00 |2007-09-12 13:12:21
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29473
[Bug target/29473] -masm=intel combined with -march=athlon64 has some issues.
--- Comment #10 from ubizjak at gmail dot com 2007-09-12 13:41 ---
(In reply to comment #9)
This still happens with GCC 4.3 when trying to bootstrap with BOOT_CFLAGS='-O2
-g -fomit-frame-pointer -masm=intel' and it blocks me from working on bug
29493.
/home/rask/build/gcc-x86_64-unknown-linux-gnu/./prev-gcc/xgcc
-B/home/rask/build/gcc-x86_64-unknown-linux-gnu/./prev-gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/ -c -DHAVE_CONFIG_H -O2 -g
-fomit-frame-pointer -masm=intel -I.
-I/home/rask/src/gcc/libiberty/../include
-W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic
/home/rask/src/gcc/libiberty/cplus-dem.c -o cplus-dem.o
/tmp/cc74KiHp.s: Assembler messages:
/tmp/cc74KiHp.s:818: Error: expecting string instruction after `rep'
make[3]: *** [cplus-dem.o] Error 1
make[3]: Leaving directory
`/home/rask/build/gcc-x86_64-unknown-linux-gnu/libiberty'
make[2]: *** [all-stage2-libiberty] Error 2
You could play a bit with line 14997 rep{\;| }ret in config/i386/i386.md:
--cut here--
;; Used by x86_machine_dependent_reorg to avoid penalty on single byte RET
;; instruction Athlon and K8 have.
(define_insn return_internal_long
[(return)
(unspec [(const_int 0)] UNSPEC_REP)]
reload_completed
rep{\;| }ret
[(set_attr length 1)
(set_attr length_immediate 0)
(set_attr prefix_rep 1)
(set_attr modrm 0)])
--cht here--
You could try rep ret, rep\;ret or rep ; ret here. Otherwise, this is an
assembler bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29473
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #3 from hjl at lucon dot org 2007-09-12 13:54 --- (In reply to comment #2) Subject: Re: [4.3 Regression] Revision 128239 causes libgomp failure Hi, I´ve just tested ia64-linux and x86_64-linux on our testers and both are clean WRT libgomp: === libgomp Summary === # of expected passes496 it might be some sort of race condition (I sometimes see libgomp failures appear and go such as: Have you compared the times to take for make check on libgomp between revision 128238 and HEAD? With C libgomp tests only, revision 128238 takes less than 15 seconds on a 1.5GHz ia64 machine. Revision 128239 takes more than 20 minutes plus random failures. libgomp.fortran/omp_parse3.f90 -O0 execution test One obvious difference is that we now consider functions produced by OMP lowering inlinable. This can be avoided by: Index: omp-low.c === *** omp-low.c (revision 128412) --- omp-low.c (working copy) *** expand_omp_parallel (struct omp_region * *** 2589,2594 --- 2589,2595 /* Inform the callgraph about the new function. */ DECL_STRUCT_FUNCTION (child_fn)-curr_properties = cfun-curr_properties; + DECL_UNINLINABLE (child_fn) = true; cgraph_add_new_function (child_fn, true); /* Fix the callgraph edges for child_cfun. Those for cfun will be It makes no differences to me. -- hjl at lucon dot org changed: What|Removed |Added CC||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #4 from jh at suse dot cz 2007-09-12 14:16 --- Subject: Re: [4.3 Regression] Revision 128239 causes libgomp failure Have you compared the times to take for make check on libgomp between revision 128238 and HEAD? With C libgomp tests only, revision 128238 takes less than 15 seconds on a 1.5GHz ia64 machine. Revision 128239 takes more than 20 minutes plus random failures. Interesting. At the moment I can't access any ia64 machine directly, just test via our mail based interface that won't let me time the test. Are those failures an timeouts? It might be some sort of deadlocking... Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #5 from hjl at lucon dot org 2007-09-12 14:24 --- (In reply to comment #4) Interesting. At the moment I can't access any ia64 machine directly, just test via our mail based interface that won't let me time the test. Are those failures an timeouts? It might be some sort of deadlocking... All failures are timeout. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
.c scan-tree-dump-times OUTER LOOP VECTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-19.c scan-tree-dump-times OUTER LOOP VECTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-21.c scan-tree-dump-times OUTER LOOP VECTORIZED. 1 === gcc Summary === # of expected passes44377 # of unexpected failures36 # of unexpected successes 4 # of expected failures 207 # of unresolved testcases 4 # of untested testcases 35 # of unsupported tests 314 /tmp/jakub/gcc/obj/gcc/xgcc version 4.3.0 20070912 (experimental) (GCC) === gfortran tests === Running target unix FAIL: gfortran.dg/do_3.F90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/do_3.F90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/do_3.F90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/do_3.F90 -O3 -g execution test === gfortran Summary === # of expected passes21091 # of unexpected failures4 # of expected failures 17 # of unsupported tests 21 /tmp/jakub/gcc/obj/gcc/testsuite/gfortran/../../gfortran version 4.3.0 20070912 (experimental) (GCC) === g++ tests === Running target unix XPASS: g++.dg/tree-ssa/copyprop-1.C scan-tree-dump-not .* = [^;]*; FAIL: g++.dg/tree-prof/indir-call-prof.C scan-tree-dump Indirect call - direct call.* AA transformation on insn FAIL: g++.dg/tree-prof/indir-call-prof.C scan-tree-dump Indirect call - direct call.* AA transformation on insn FAIL: g++.dg/tree-prof/indir-call-prof.C scan-tree-dump Indirect call - direct call.* AA transformation on insn FAIL: g++.dg/tree-prof/indir-call-prof.C scan-tree-dump Indirect call - direct call.* AA transformation on insn FAIL: g++.dg/tree-prof/indir-call-prof.C scan-tree-dump Indirect call - direct call.* AA transformation on insn FAIL: g++.dg/tree-prof/indir-call-prof.C scan-tree-dump Indirect call - direct call.* AA transformation on insn FAIL: g++.dg/tree-prof/indir-call-prof.C scan-tree-dump Indirect call - direct call.* AA transformation on insn === g++ Summary === # of expected passes15848 # of unexpected failures7 # of unexpected successes 1 # of expected failures 86 # of unsupported tests 129 /tmp/jakub/gcc/obj/gcc/testsuite/g++/../../g++ version 4.3.0 20070912 (experimental) (GCC) === objc tests === Running target unix === objc Summary === # of expected passes1810 # of expected failures 7 # of unsupported tests 25 /tmp/jakub/gcc/obj/gcc/xgcc version 4.3.0 20070912 (experimental) (GCC) === libffi tests === Running target unix === libffi Summary === # of expected passes1108 # of unsupported tests 8 === libgomp tests === Running target unix === libgomp Summary === # of expected passes1607 === libjava tests === Running target unix FAIL: getlocalvartable output FAIL: Throw_3 -O3 output - source compiled test FAIL: Throw_3 -O3 -findirect-dispatch output - source compiled test === libjava Summary === # of expected passes2547 # of unexpected failures3 === libmudflap tests === Running target unix FAIL: libmudflap.c++/pass41-frag.cxx execution test ... Many failures, but this was make -j16 -k check on 8way ia64 and libmudflap tests are horribly sensitive to loadavg. FAIL: libmudflap.cth/pass40-frag.c (-O3) output pattern test === libmudflap Summary === # of expected passes1493 # of unexpected failures333 === libstdc++ tests === Running target unix FAIL: 22_locale/moneypunct_byname/named_equivalence.cc (test for excess errors) WARNING: 22_locale/moneypunct_byname/named_equivalence.cc compilation failed to produce executable XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for excess errors) XPASS: 27_io/fpos/14320-1.cc execution test === libstdc++ Summary === # of expected passes5169 # of unexpected failures1 # of unexpected successes 2 # of expected failures 56 # of unsupported tests 8 Compiler version: 4.3.0 20070912 (experimental) (GCC) Platform: ia64-unknown-linux-gnu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #7 from jakub at gcc dot gnu dot org 2007-09-12 14:39 --- BTW, when you say -fno-inline-small-functions cures this for you, is the problem on libgomp side or in the generated gomp tests? I.e. if you build libgomp with the default -O2 -finline-small-functions and run make check in libgomp with RUNTESTFLAGS=--target_board=unix/-fno-inline-small-functions do the problems go away? Or vice versa, build libgomp built with -O2 -fno-inline-small-functions vs. RUNTEST=--target_board=unix/-finline-small-functions ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #9 from hjl at lucon dot org 2007-09-12 14:41 --- (In reply to comment #7) BTW, when you say -fno-inline-small-functions cures this for you, is the problem on libgomp side or in the generated gomp tests? I.e. if you build libgomp Apparently not. From http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00581.html === libgomp tests === Running target unix FAIL: libgomp.c/pr26943-2.c execution test FAIL: libgomp.fortran/omp_parse2.f90 -O0 execution test FAIL: libgomp.fortran/omp_parse2.f90 -O2 execution test FAIL: libgomp.fortran/omp_parse2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: libgomp.fortran/omp_parse3.f90 -O0 execution test === libgomp Summary === # of expected passes1602 # of unexpected failures5 The nature of this bug is random failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #8 from hjl at lucon dot org 2007-09-12 14:40 --- (In reply to comment #6) Cannot reproduce this with r128425 + PR32337 + PR32338 fix (8way ia64, make -j16 -k check): From http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00573.html === libgomp tests === Running target unix FAIL: libgomp.c/pr26943-2.c execution test FAIL: libgomp.c/pr26943-4.c execution test FAIL: libgomp.c/pr29947-1.c execution test FAIL: libgomp.fortran/omp_parse3.f90 -O0 execution test Have you checked the times it takes to run make check on libgomp? The problem is random failure with timeout. make check may pass, but takes much longer to finish. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug rtl-optimization/19580] [4.0/4.1/4.2/4.3 Regression] missed load/store motion
--- Comment #32 from rguenth at gcc dot gnu dot org 2007-09-12 14:44 --- load-store motion at the tree level should really catch this. For this it needs to be extended to disambiguate aliases by looking at the actual memory references: bb 4: # r_8 = PHI r_29(5), r_23(D)(3) # n_11 = PHI n_3(5), n_14(3) # VUSE r_8 D.1137_4 = r[0]; # VUSE r_8 D.1138_5 = r[5]; D.1139_6 = D.1138_5 + D.1137_4; # r_24 = VDEF r_8 r[0] = D.1139_6; # VUSE r_24 D.1140_7 = r[1]; D.1141_9 = D.1139_6 + D.1140_7; ... # r_29 = VDEF r_28 r[5] = D.1148_21; n_3 = n_11 + -1; if (n_3 != 0) goto bb 5; else goto bb 6; Zdenek, I think you had a patch to make lim more precise in this regard? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19580
[Bug rtl-optimization/19580] [4.0/4.1/4.2/4.3 Regression] missed load/store motion
--- Comment #33 from rakdver at gcc dot gnu dot org 2007-09-12 14:49 --- Zdenek, I think you had a patch to make lim more precise in this regard? Yes. Revital Eres was trying to put it into shape suitable for mainline a few months ago, I am not sure what is the status of that? -- rakdver at gcc dot gnu dot org changed: What|Removed |Added CC||eres at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19580
[Bug rtl-optimization/21527] [4.0/4.1/4.2/4.3 Regression] BYTEmark bitmap test: Regression with Profiled Optimization
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-09-12 15:03 --- For 4.3 we improve runtime with FDO and -O2, in both cases, with and without FDO 4.3 scores 20% better than 3.4. With 4.1 I also see better scores with FDO. For -O3 scores are the same with/w/o FDO for 4.1 and trunk. - FIXED. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|4.1.3 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21527
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #10 from jakub at gcc dot gnu dot org 2007-09-12 15:04 --- The whole testsuite takes roughly 10 minutes: head -n2 libgomp.log; tail -n4 libgomp.log Test Run By root on Wed Sep 12 10:47:12 2007 Native configuration is ia64-unknown-linux-gnu === libgomp Summary === # of expected passes1607 runtest completed at Wed Sep 12 10:57:39 2007 and just RUNTESTFLAGS=c.exp takes around 30sec, no failures here (stock RHEL5). Can you try to run make check with say libgomp.so* from some older build before you started seeing this or from 4.2? Knowing whether your libgomp was miscompiled or if the testcases themselves are miscompiled is really crucial to finding out what's going on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug rtl-optimization/19580] [4.0/4.1/4.2/4.3 Regression] missed load/store motion
--- Comment #34 from eres at il dot ibm dot com 2007-09-12 15:09 --- I did not engage with it for some time so I doubt it if my latest version of the patch (which is originally in http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02331.html) is suitable for current mainline. I will certainly try to re-apply and post it as soon as possible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19580
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #11 from hjl at lucon dot org 2007-09-12 15:36 --- (In reply to comment #10) you started seeing this or from 4.2? Knowing whether your libgomp was miscompiled or if the testcases themselves are miscompiled is really crucial to finding out what's going on. I verified that it was libgomp which was miscompiled. BTW, I am running RHEL4 U5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #12 from jakub at gcc dot gnu dot org 2007-09-12 15:48 --- Can you see if e.g. building whole libgomp with -O0 fixes it? If yes, can you do a binary search which of the sources is miscompiled? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug ada/32407] [4.3 regression] ACATS cd92001 fails
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-09-12 15:53 --- Subject: Bug 32407 Author: ebotcazou Date: Wed Sep 12 15:52:57 2007 New Revision: 128441 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128441 Log: PR ada/26797 PR ada/32407 * utils.c (unchecked_convert): Use a subtype as the intermediate type in the special VIEW_CONVERT_EXPR case. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/utils.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32407
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #44 from ebotcazou at gcc dot gnu dot org 2007-09-12 15:53 --- Subject: Bug 26797 Author: ebotcazou Date: Wed Sep 12 15:52:57 2007 New Revision: 128441 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128441 Log: PR ada/26797 PR ada/32407 * utils.c (unchecked_convert): Use a subtype as the intermediate type in the special VIEW_CONVERT_EXPR case. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/utils.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug fortran/33408] New: internal compiler error: tree check: expected type_decl, have in debug_flush_symbol_queue, at final.c:3986
I get a crash when I try to compile this program with the given options. The problem seems to related to the size of the program - I tried pulling out many different sections and it no longer crashed - [dranta:~/junk] dir% gfortran -fcray-pointer -fno-automatic -g -O0 -c out.f outt.F:3155.19: common/aux14/ 1 Warning: Named COMMON block 'aux14' at (1) shall be of the same size outt.F:4193.19: common/aux14/stfv(lnv),fni(lnv),fxi(lnv),fyi(lnv),fzi(lnv), 1 Warning: Named COMMON block 'aux14' at (1) shall be of the same size outt.F:4502.19: common/aux14/pxs(lnv),pys(lnv),pzs(lnv),pxt(lnv),pyt(lnv), 1 Warning: Named COMMON block 'aux14' at (1) shall be of the same size outt.F:9616.19: common/aux14/ic(9085),icount 1 Warning: Named COMMON block 'aux14' at (1) shall be of the same size outt.F: In function 'autobug1': outt.F:22832: internal compiler error: tree check: expected type_decl, have in debug_flush_symbol_queue, at final.c:3986 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [dranta:~/junk] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.10.0 Configured with: ../gcc/configure --disable-bootstrap --enable-multilib --prefix=/usr/local/gfortran --enable-languages=c,fortran Thread model: posix gcc version 4.3.0 20070912 (experimental) (GCC) -- Summary: internal compiler error: tree check: expected type_decl, have in debug_flush_symbol_queue, at final.c:3986 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC host triplet: powerpc-apple-darwin8.10.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33408
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #45 from ebotcazou at gcc dot gnu dot org 2007-09-12 15:55 --- At long last. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||09/msg01100.html Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug fortran/33408] internal compiler error: tree check: expected type_decl, have in debug_flush_symbol_queue, at final.c:3986
--- Comment #1 from dir at lanl dot gov 2007-09-12 15:55 --- Created an attachment (id=14195) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14195action=view) The fortran source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33408
[Bug ada/32407] [4.3 regression] ACATS cd92001 fails
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-09-12 15:56 --- Fixed on mainline. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||09/msg01100.html Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32407
[Bug middle-end/31023] Fold is agnostic of integer sub-types
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-12 16:05:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31023
[Bug c++/33409] New: Overload Resolution Succeeds When Actually Ambiguous.
With the following command line:
[c:\hack]==#9658; gcc -v -save-temps --pedantic -c a.cpp
Reading specs from /mingw/lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
--enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry
--disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt
--without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
cc1plus -E -quiet -v -iprefix ../lib/gcc/mingw32/3.4.2/ a.cpp -pedantic -o
a.ii
ignoring nonexistent directory
../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2
ignoring nonexistent directory
../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/mingw32
ignoring nonexistent directory
../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/backward
ignoring nonexistent directory ../lib/gcc/mingw32/3.4.2/../../../../include
ignoring nonexistent directory ../lib/gcc/mingw32/3.4.2/include
ignoring nonexistent directory
../lib/gcc/mingw32/3.4.2/../../../../mingw32/include
ignoring nonexistent directory /mingw/mingw32/include
#include ... search starts here:
#include ... search starts here:
/mingw/include/c++/3.4.2
/mingw/include/c++/3.4.2/mingw32
/mingw/include/c++/3.4.2/backward
/mingw/include
/mingw/include
/mingw/lib/gcc/mingw32/3.4.2/include
/mingw/include
End of search list.
cc1plus -fpreprocessed a.ii -quiet -dumpbase a.cpp -auxbase a -pedantic
-version -o a.s
GNU C++ version 3.4.2 (mingw-special) (mingw32)
compiled by GNU C version 3.4.2 (mingw-special).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=130924 as -o
a.o a.s
where a.cpp contains the following:
class A
{
public:
A( double );
operator long();
};
A operator% ( const A, const A );
void x()
{
A g(0);
double d = 1.2;
d = d % g; //Should report on ambiguous call
}
I get no complaint from gcc. However, the call is ambiguous according to the
ISO C++ 2003 Standard. The rationale follows:
1. The candidate functions are a) operator%(const A , const A ) and b)
built-in operator % (arguments: both integral/enumeration)
2. Both candidates has the same # of parameters.
3. Implicit conversion sequences for each argument:
double-const A via copy-initializing a temporary const A
A-const A, Exact Match via reference binding and Qualification
Adjustment
double-integral/enumeration via floating-integral conversion
A-long via the User-Defined Conversion Sequence of Identity
Conversion-A::operator long() invocation-Identity Conversion
4. ICS1(non built-in): User-Defined Conversion Sequence
ICS2(non built-in): Qualification Adjustment
ICS1(built-in): Floating-integral conversion
ICS2(built-in): User-Defined Conversion Sequence
5. By 13.3.3.2,
ICS2(non built-in) represents a better conversion sequence than
ICS2(built-in): Standard v. User-Defined
ICS1(non built-in) represents a worse conversion sequence than
ICS1(built-in): User-Defined v. Standard
Therefore, neither operator invocation constitutes a best viable function and
the program is ill-formed.
I ran this by the people at EDG and received a reply agreeing with my analysis.
--
Summary: Overload Resolution Succeeds When Actually Ambiguous.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martinezfive at comcast dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33409
[Bug c++/33409] Overload Resolution Succeeds When Actually Ambiguous.
--- Comment #1 from martinezfive at comcast dot net 2007-09-12 16:13 --- Created an attachment (id=14196) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14196action=view) a.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33409
[Bug c++/33407] [4.1/4.3 Regression] C++ operator new and new expression do not change dynamic type
--- Comment #5 from jakub at gcc dot gnu dot org 2007-09-12 16:13 --- Could we limit adding of the CHANGE_DYNAMIC_TYPE_EXPRs just to the case where operator new or __attribute__((malloc)) marked FUNCTION_DECL is not external? That would be solid even for LTO, if you LTO and have say malloc implemented among the stuff you read in, then we need to handle that carefully, but if it is for the compiler just a black box in libc, there is no need to pollute the IL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33407
[Bug fortran/33106] Access of components of public entities of private types wrongly allowed
--- Comment #6 from burnus at gcc dot gnu dot org 2007-09-12 16:36 --- See also http://groups.google.com/group/comp.lang.fortran/msg/362cea390359d128 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33106
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #13 from hjl at lucon dot org 2007-09-12 16:51 --- (In reply to comment #12) Can you see if e.g. building whole libgomp with -O0 fixes it? If yes, can you do a binary search which of the sources is miscompiled? Thanks. When I replaced bar.o with the bad one, C only make check went from 13 seconds to 84 seconds. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug fortran/33408] ICE: tree check: expected type_decl, have in debug_flush_symbol_queue, at final.c:3986
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-12 16:52 --- I cannot reproduce this on x86-64 (Rev. 128440 of today). -- burnus at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|powerpc-apple-darwin8.10.0 | GCC target triplet||powerpc-apple-darwin8.10.0 Keywords||ice-on-valid-code Summary|internal compiler error:|ICE: tree check: expected |tree check: expected|type_decl, have in |type_decl, have in |debug_flush_symbol_queue, at |debug_flush_symbol_queue, at|final.c:3986 |final.c:3986| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33408
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #14 from jakub at gcc dot gnu dot org 2007-09-12 16:59 --- Can you please attach bad and good bar.s (with -fverbose-asm) and also -ftree-dump-optimized dump from both? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #15 from hjl at lucon dot org 2007-09-12 17:10 --- Created an attachment (id=14197) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14197action=view) Good bar.s and bar.c.117t.optimized generated by revision 128238 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #16 from hjl at lucon dot org 2007-09-12 17:11 --- Created an attachment (id=14198) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14198action=view) Bad bar.s and bar.c.121t.optimized generated by revision 128239 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #17 from hjl at lucon dot org 2007-09-12 17:18 --- gomp_barrier_wait_end in bar.c.121t.optimized has __asm__ __volatile__(break 0x10:=r r15, =r out0, =r out1, =r out2, =r out3:r r15, r out0, r out1, r out2, r out3:b6, f15, f14, f13, f12, f11, f10, f9, f8, f7, f6, p15, p14, p13, p12, p11, p10, p9, p8, p7, p6, r31, r30, r29, r28, r27, r26, r25, r24, r23, r22, r21, r20, r19, r18, r17, r16, r14, r13, r12, r11, r9, r3, r2, out7, out6, out5, out4, r10, r8, memory); But r15, out0, out1, out2 and out3 aren't initialized at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #18 from hjl at lucon dot org 2007-09-12 17:20 ---
Revision 128239 miscompiled
static inline void
sys_futex0(int *addr, int op, int val)
{
register long out0 asm (out0) = (long) addr;
register long out1 asm (out1) = op;
register long out2 asm (out2) = val;
register long out3 asm (out3) = 0;
register long r15 asm (r15) = SYS_futex;
__asm __volatile (break 0x10
: =r(r15), =r(out0), =r(out1), =r(out2), =r(out3)
: r(r15), r(out0), r(out1), r(out2), r(out3)
: memory, r8, r10, out4, out5, out6, out7,
/* Non-stacked integer registers, minus r8, r10, r15. */
r2, r3, r9, r11, r12, r13, r14, r16, r17, r18,
r19, r20, r21, r22, r23, r24, r25, r26, r27,
r28, r29, r30, r31,
/* Predicate registers. */
p6, p7, p8, p9, p10, p11, p12, p13, p14, p15,
/* Non-rotating fp registers. */
f6, f7, f8, f9, f10, f11, f12, f13, f14, f15,
/* Branch registers. */
b6);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #19 from jakub at gcc dot gnu dot org 2007-09-12 17:49 ---
Here is self-contained source:
void
sys_futex0(int *addr, int op, int val)
{
register long out0 asm (out0) = (long) addr;
register long out1 asm (out1) = op;
register long out2 asm (out2) = val;
register long out3 asm (out3) = 0;
register long r15 asm (r15) = 1230;
__asm __volatile (break 0x10
: =r(r15), =r(out0), =r(out1), =r(out2), =r(out3)
: r(r15), r(out0), r(out1), r(out2), r(out3)
: memory, r8, r10, out4, out5, out6, out7,
/* Non-stacked integer registers, minus r8, r10, r15. */
r2, r3, r9, r11, r12, r13, r14, r16, r17, r18,
r19, r20, r21, r22, r23, r24, r25, r26, r27,
r28, r29, r30, r31,
/* Predicate registers. */
p6, p7, p8, p9, p10, p11, p12, p13, p14, p15,
/* Non-rotating fp registers. */
f6, f7, f8, f9, f10, f11, f12, f13, f14, f15,
/* Branch registers. */
b6);
}
vs.
void
sys_futex0(int *addr, int op, int val)
{
register long out0 asm (out0) = (long) addr;
register long out1 asm (out1) = op;
register long out2 asm (out2) = val;
register long out3 asm (out3) = 0;
register long r15 asm (r15) = 1230;
__asm __volatile (break 0x10
:
: r(r15), r(out0), r(out1), r(out2), r(out3)
: memory, r8, r10, out4, out5, out6, out7,
/* Non-stacked integer registers, minus r8, r10, r15. */
r2, r3, r9, r11, r12, r13, r14, r16, r17, r18,
r19, r20, r21, r22, r23, r24, r25, r26, r27,
r28, r29, r30, r31,
/* Predicate registers. */
p6, p7, p8, p9, p10, p11, p12, p13, p14, p15,
/* Non-rotating fp registers. */
f6, f7, f8, f9, f10, f11, f12, f13, f14, f15,
/* Branch registers. */
b6);
}
The former is miscompiled by sdse1 pass:
Deleted dead store '# STORES: { out0D.1189 }
out0D.1189 ={v} addr.0D.1194_2'
Deleted dead store '# STORES: { out1D.1190 }
out1D.1190 ={v} out1.1D.1195_4'
Deleted dead store '# STORES: { out2D.1191 }
out2D.1191 ={v} out2.2D.1196_6'
Deleted dead store '# STORES: { out3D.1192 }
out3D.1192 ={v} 0'
Deleted dead store '# STORES: { r15D.1193 }
r15D.1193 ={v} 1230'
sys_futex0 (addrD.1184, opD.1185, valD.1186)
{
register long intD.2 r15D.1193 __asm__ (*r15);
register long intD.2 out3D.1192 __asm__ (*out3);
register long intD.2 out2D.1191 __asm__ (*out2);
register long intD.2 out1D.1190 __asm__ (*out1);
register long intD.2 out0D.1189 __asm__ (*out0);
long intD.2 out2.2D.1196;
long intD.2 out1.1D.1195;
long intD.2 addr.0D.1194;
# BLOCK 2
# PRED: ENTRY (fallthru,exec)
addr.0D.1194_2 = (long intD.2) addrD.1184_1(D);
out1.1D.1195_4 = (long intD.2) opD.1185_3(D);
out2.2D.1196_6 = (long intD.2) valD.1186_5(D);
# STORES: { out0D.1189 out1D.1190 out2D.1191 out3D.1192 r15D.1193 }
__asm__ __volatile__(break 0x10:=r r15D.1193, =r out0D.1189, =r
out1D.1190, =r out2D.1191, =r out3D.1192:r r1
5D.1193, r out0D.1189, r out1D.1190, r out2D.1191, r out3D.1192:b6,
f15, f14, f13, f12, f11, f10, f9, f8
, f7, f6, p15, p14, p13, p12, p11, p10, p9, p8, p7,
p6, r31, r30, r29, r28, r27, r26, r25,
r24, r23, r22, r21, r20, r19, r18, r17, r16, r14, r13,
r12, r11, r9, r3, r2, out7, out6, ou
t5, out4, r10, r8, memory);
return;
# SUCC: EXIT
while the latter is not:
;; Function sys_futex0 (sys_futex0)
sys_futex0 (addrD.1184, opD.1185, valD.1186)
{
register long intD.2 r15D.1193 __asm__ (*r15);
register long intD.2 out3D.1192 __asm__ (*out3);
register long intD.2 out2D.1191 __asm__ (*out2);
register long intD.2 out1D.1190 __asm__ (*out1);
register long intD.2 out0D.1189 __asm__ (*out0);
long intD.2 out2.2D.1196;
long intD.2 out1.1D.1195;
long intD.2 addr.0D.1194;
# BLOCK 2
# PRED: ENTRY (fallthru,exec)
addr.0D.1194_2 = (long intD.2) addrD.1184_1(D);
# STORES: { out0D.1189 }
out0D.1189 ={v} addr.0D.1194_2;
out1.1D.1195_4 = (long intD.2) opD.1185_3(D);
# STORES: { out1D.1190 }
out1D.1190 ={v} out1.1D.1195_4;
out2.2D.1196_6 = (long intD.2) valD.1186_5(D);
# STORES: { out2D.1191 }
out2D.1191 ={v} out2.2D.1196_6;
# STORES: { out3D.1192 }
out3D.1192 ={v} 0;
# STORES: { r15D.1193 }
r15D.1193 ={v} 1230;
# LOADS: { out0D.1189 out1D.1190 out2D.1191 out3D.1192 r15D.1193 }
__asm__ __volatile__(break 0x10::r r15D.1193, r out0D.1189, r
out1D.1190, r out2D.1191, r out3D.1192:b6, f15
, f14, f13, f12, f11, f10, f9, f8, f7, f6, p15, p14,
p13, p12, p11, p10, p9, p8, p7, p6,
r31, r30, r29, r28, r27, r26, r25, r24, r23, r22, r21,
r20, r19, r18, r17, r16, r14, r13, r12
, r11, r9, r3, r2, out7, out6, out5, out4, r10, r8,
memory);
return;
# SUCC: EXIT
Seems if the same reg is both input and output it is just among
STORED_SYMS, not LOADED_SYMS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #20 from jakub at gcc dot gnu dot org 2007-09-12 18:26 ---
append_vuse has:
static inline void
append_vuse (tree var)
{
tree sym;
if (TREE_CODE (var) != SSA_NAME)
{
tree mpt;
var_ann_t ann;
/* If VAR belongs to a memory partition, use it instead of VAR. */
mpt = memory_partition (var);
if (mpt)
var = mpt;
/* Don't allow duplicate entries. */
ann = get_var_ann (var);
if (ann-in_vuse_list || ann-in_vdef_list)
return;
ann-in_vuse_list = true;
sym = var;
}
else
sym = SSA_NAME_VAR (var);
VEC_safe_push (tree, heap, build_vuses, var);
bitmap_set_bit (build_loads, DECL_UID (sym));
}
For VAR_DECL with DECL_HARD_REGISTER set, if it is only in the input list of
asm,
it is added as vuse/load, if it is only in output list of am, it is added as
vdef/store. But the above /* Don't allow duplicate entries. */ means
that if there is =r (x) : r (x) with VAR_DECL DECL_HARD_REGISTER x, it is
only marked as store/vdef, not as load/vuse.
No matter whether it is right or wrong in tree-ssa-operands.c, I think
sdse should just avoid removing VAR_DECL DECL_HARD_REGISTER store elimination.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug tree-optimization/33410] New: ICE in iv_analyze_expr, at loop-iv.c:934
[ forwarded from http://bugs.debian.org/442036 ]
[EMAIL PROTECTED]:/src/delta/bin% cat test.c
long double f(long double *data, long n) {
long double max = 0;
long i;
for (i = 0; i n; i++) {
if (data[i])
max = 1;
}
return max;
}
[EMAIL PROTECTED]:/src/delta/bin% gcc -c -O2 test.c
[EMAIL PROTECTED]:/src/delta/bin% gcc -c -O3 test.c
test.c: In function 'f':
test.c:9: internal compiler error: in iv_analyze_expr, at loop-iv.c:911
Please submit a full bug report,
Reproduced with Debian's 4.2.1 and 4.3.0 20070829 r127913. Compiler is
configured to 128 bit long double.
--Falk
--
Summary: ICE in iv_analyze_expr, at loop-iv.c:934
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
GCC build triplet: alpha-linux-gnu
GCC host triplet: alpha-linux-gnu
GCC target triplet: alpha-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
[Bug rtl-optimization/33410] ICE in iv_analyze_expr, at loop-iv.c:934
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-12 19:15 --- loop-iv.c is RTL. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |rtl-optimization Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
[Bug fortran/33408] ICE: tree check: expected type_decl, have in debug_flush_symbol_queue, at final.c:3986
--- Comment #3 from dir at lanl dot gov 2007-09-12 19:17 --- It compiles on the Intel Macintosh with no problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33408
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #21 from wilson at specifix dot com 2007-09-12 19:30 --- Subject: Re: [4.3 Regression] Revision 128239 causes libgomp failure The failure occurs in the sdse (simple dead store elimination) pass. It looks like it is confused by an extended asm statement with input/output operands. It thinks these operands are not read by the asm. If the only use of a variable is inside such an asm, then sdse will think that the variable is never read, and optimize away stores to it. I haven't tried debugging sdse yet to see exactly what is going wrong. Jim -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug java/33411] New: Java Build Fails - internal compiler error: internal consistency failure
I configured with -
../gcc/configure --prefix=/usr/local/java --enable-languages=c,c++,java
--with-ecj-jar=/Users/dir/gfortran/gcc/ecj.jar --enable-java-awt=gtk
--enable-gtk-cairo --disable-bootstrap --disable-multilib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
The build failed with -
libtool: compile: /Users/dir/gfortran/ibin/gcc/gcj
-B/Users/dir/gfortran/ibin/powerpc-apple-darwin8.10.0/libjava/
-B/Users/dir/gfortran/ibin/gcc/ -fclasspath=
-fbootclasspath=../../../gcc/libjava/classpath/lib --encoding=UTF-8
-Wno-deprecated -fbootstrap-classes -g -O2 -c
-fsource-filename=/Users/dir/gfortran/ibin/powerpc-apple-darwin8.10.0/libjava/classpath/lib/classes
-MT gnu/javax/imageio/gif.lo -MD -MP -MF gnu/javax/imageio/gif.deps
@gnu/javax/imageio/gif.list -o gnu/javax/imageio/gif.o /dev/null 21
/bin/sh ./libtool --tag=GCJ --mode=compile /Users/dir/gfortran/ibin/gcc/gcj
-B/Users/dir/gfortran/ibin/powerpc-apple-darwin8.10.0/libjava/
-B/Users/dir/gfortran/ibin/gcc/ -fclasspath=
-fbootclasspath=../../../gcc/libjava/classpath/lib --encoding=UTF-8
-Wno-deprecated -fbootstrap-classes -g -O2 -c -o gnu/javax/imageio/jpeg.lo
-fsource-filename=/Users/dir/gfortran/ibin/powerpc-apple-darwin8.10.0/libjava/classpath/lib/classes
-MT gnu/javax/imageio/jpeg.lo -MD -MP -MF gnu/javax/imageio/jpeg.deps
@gnu/javax/imageio/jpeg.list
libtool: compile: /Users/dir/gfortran/ibin/gcc/gcj
-B/Users/dir/gfortran/ibin/powerpc-apple-darwin8.10.0/libjava/
-B/Users/dir/gfortran/ibin/gcc/ -fclasspath=
-fbootclasspath=../../../gcc/libjava/classpath/lib --encoding=UTF-8
-Wno-deprecated -fbootstrap-classes -g -O2 -c
-fsource-filename=/Users/dir/gfortran/ibin/powerpc-apple-darwin8.10.0/libjava/classpath/lib/classes
-MT gnu/javax/imageio/jpeg.lo -MD -MP -MF gnu/javax/imageio/jpeg.deps
@gnu/javax/imageio/jpeg.list -fno-common -o gnu/javax/imageio/.libs/jpeg.o
/var/tmp//cchBksKqjx: In class 'gnu.javax.imageio.jpeg.DCT':
/var/tmp//cchBksKqjx: In method
'gnu.javax.imageio.jpeg.DCT.slow_idct(double[][])':
/var/tmp//cchBksKqjx:0: error: invalid rtl sharing found in the insn
(insn 476 475 477 37
../../../../../gcc/libjava/classpath/gnu/javax/imageio/jpeg/DCT.java:119 (set
(reg:SI 333)
(mem/c/i:SI (plus:SI (reg/f:SI 113 sfp)
(const_int 72 [0x48])) [19 S4 A32])) 328 {*movsi_internal1}
(expr_list:REG_EQUAL (fix:SI (reg/v:DF 136 [ D.1723 ]))
(nil)))
/var/tmp//cchBksKqjx:0: error: shared rtx
(mem/c/i:SI (plus:SI (reg/f:SI 113 sfp)
(const_int 72 [0x48])) [19 S4 A32])
/var/tmp//cchBksKqjx:0: internal compiler error: internal consistency failure
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make[3]: *** [gnu/javax/imageio/jpeg.lo] Error 1
make[3]: *** Waiting for unfinished jobs
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-target-libjava] Error 2
make: *** [all] Error 2
--
Summary: Java Build Fails - internal compiler error: internal
consistency failure
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dir at lanl dot gov
GCC host triplet: powerpc-apple-darwin8.10.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33411
[Bug java/33411] Java Build Fails - internal compiler error: internal consistency failure
--- Comment #1 from andreast at gcc dot gnu dot org 2007-09-12 19:51 --- *** This bug has been marked as a duplicate of 33406 *** -- andreast at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33411
[Bug bootstrap/33406] At revision 128385 Bootstraping PPC Darwin still fail in Java
--- Comment #2 from andreast at gcc dot gnu dot org 2007-09-12 19:51 --- *** Bug 33411 has been marked as a duplicate of this bug. *** -- andreast at gcc dot gnu dot org changed: What|Removed |Added CC||dir at lanl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33406
[Bug fortran/33106] Access of components of public entities of private types wrongly allowed
--- Comment #7 from burnus at gcc dot gnu dot org 2007-09-12 19:53 --- Mine -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dfranke at gcc dot gnu dot |burnus at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33106
[Bug fortran/33412] New: Bind(C): ELEMENTAL procedure conflicts with BIND(C)
C1242 (R1227) A prefix shall not specify ELEMENTAL if proc-language-binding-spec appears in the function-stmt or subroutine-stmt. NAG f95: Error: z.f90, line 1: BIND(C) is not allowed for elemental procedure A Example: elemental function a(b) bind(c) use iso_c_binding real(c_float) :: a, b intent(in) :: b a = b end function a -- Summary: Bind(C): ELEMENTAL procedure conflicts with BIND(C) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: accepts-invalid 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=33412
[Bug target/33406] [4.3 Regression] At revision 128385 Bootstraping PPC Darwin still fail in Java
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|bootstrap |target Keywords||build, ice-on-valid-code Summary|At revision 128385 |[4.3 Regression] At revision |Bootstraping PPC Darwin |128385 Bootstraping PPC |still fail in Java |Darwin still fail in Java Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33406
[Bug target/33406] [4.3 Regression] At revision 128385 Bootstraping PPC Darwin still fail in Java
--- Comment #3 from andreast at gcc dot gnu dot org 2007-09-12 20:32 --- --disable-checking succeeded with rev 128389. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33406
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug target/33406] [4.3 Regression] At revision 128385 Bootstraping PPC Darwin still fail in Java
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-12 20:57 --- I think this is the same issue as PR 33348. The shared RTX are the same and the original RTX is the same type of RTX (I forgot to paste it into the bug though). -- Pinski -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||33348 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33406
[Bug fortran/33339] GFORTRAN OPTIMIZATION ERROR ABOVE -O0 FOR MPICH2 TEST F90_RMA/BASEATTRWINF90.F90
--- Comment #6 from longb at cray dot com 2007-09-12 21:05 --- Subject: Re: GFORTRAN OPTIMIZATION ERROR ABOVE -O0 FOR MPICH2 TEST F90_RMA/BASEATTRWINF90.F90 sgk at troutmask dot apl dot washington dot edu wrote: --- Comment #5 from sgk at troutmask dot apl dot washington dot edu 2007-09-10 18:28 --- Subject: Re: GFORTRAN OPTIMIZATION ERROR ABOVE -O0 FOR MPICH2 TEST F90_RMA/BASEATTRWINF90.F90 On Mon, Sep 10, 2007 at 04:03:21PM -, longb at cray dot com wrote: gcc version 4.2.1 20070719 (rpm:3) Note: The version of gcc we are using is not the same as the one you noted, and for the XT systems all linking is static. I checked my version again, and it was 4.2.1 20070523. There aren't many significant changes between this version and yours to at least the Fortran front-end. I just rebuild 4.2.2 (note it's been marked for a release) and get GNU F95 version 4.2.2 20070905 (prerelease) (x86_64-portbld-freebsd7.0) Your program with my addition and static linking gives node10:kargl[254] ../mpich2/bin/mpiexec -machinefile mf1 -n 1 ./long Got right value for WIN_DISP_UNIT ( 4 , should be 4 ) node10:kargl[255] ./long Got right value for WIN_DISP_UNIT ( 4 , should be 4 ) Our version of mpich2 appears to be older. I can ask the MPI group for a newer version. The mpich2 changelog suggests that there may be some changes which effect gfortran+mpich2. I had our MPI guy run the test with a virgin mpich2 build and he also finds no error. This appears to be a bug in the version of the mpich2 library we have on our system. I've reassigned the bug to them. Please close the bug against gfortran. Cheers, Bil -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
[Bug target/33413] New: Please provide __sync_lock_test_and_set builtin for ARM using swap insn
For most ARM architecture variants, the only atomic operation is swap. The semantics of the SWP instruction are what gcc calls __sync_lock_test_and_set (a rather odd name since the set is unconditional). Would it be possible to add a __sync_lock_test_and_set builtin for ARM that generates a SWP instruction? It would be useful to also provide a predefined macro that can be tested to determine whether the builtin is implemented. Typically, code that wants to do architecture-independent atomic operations will want to do something like: #if have atomic add etc ... atomic operations using those builtins #elsif have atomic swap ... atomic operations using swap #else ... atomic operations using pthreads, or #error #end I understand that __GCC_HAVE_SYNC_COMPARE_AND_SWAP_n can be tested for the first #if above (on sufficiently new compilers), on the basis that an architecture that provides compare-and-swap can use it to synthesize all of the other builtin atomic operations. However, swap is not sufficient to implement the other builtins without some additional constraints, e.g. a sentinel value, and assumptions about the threading model. For discussions please see: http://thread.gmane.org/gmane.comp.gcc.help/21113 Thanks, Phil. -- Summary: Please provide __sync_lock_test_and_set builtin for ARM using swap insn Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: spam_from_gcc_bugzilla at chezphil dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33413
[Bug target/32552] [4.3 Regression] Runtime failure in SPEC CPU2000 benchmark fma3d and applu
--- Comment #15 from jakub at gcc dot gnu dot org 2007-09-12 21:21 --- H.J. committed this earlier today: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128409 -- 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=32552
[Bug fortran/33343] ICE (segfault) on invalid code with wrongly shaped arguments to elemental procedures
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-12 21:26 --- 12.7.2 Elemental function actual arguments and results [...] For those elemental functions that have more than one argument, all actual arguments shall be conformable. conformable (2.4.5) : Two arrays are said to be conformable if they have the same shape. A scalar is conformable with any array. We should probably add such a check to interface.c's compare_actual_formal. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33343
[Bug fortran/33339] GFORTRAN OPTIMIZATION ERROR ABOVE -O0 FOR MPICH2 TEST F90_RMA/BASEATTRWINF90.F90
--- Comment #7 from kargl at gcc dot gnu dot org 2007-09-12 22:04 --- Closing the bug at Bill's request. The bug appears to be local to his setup. Thanks Bill for the bug report; if you have future problems don't hesitate in sending a bug report. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #22 from wilson at specifix dot com 2007-09-12 23:35 ---
Subject: Re: [4.3 Regression] Revision 128239
causes libgomp failure
jakub at gcc dot gnu dot org wrote:
No matter whether it is right or wrong in tree-ssa-operands.c, I think
sdse should just avoid removing VAR_DECL DECL_HARD_REGISTER store elimination.
This isn't a volatile register, nor a global register variable, so there
should be no problem performing dead store elimination on it. I think
tree-ssa-operands.c needs to be fixed.
I'm not a tree-ssa expert, but the fix needed in tree-ssa-operands.c
seems simple enough. The append_vuse function does two things, it keeps
a list of v_uses, and it keeps a list of loads. We don't want a v_use
if we already have a v_def, but we still need to mark it as a load. We
can do that with a little rearrangement of the code. Like this.
This works for the testcase, but has had no other testing as yet.
2007-09-12 James E. Wilson [EMAIL PROTECTED]
* tree-ssa-operands.c (append_vuse): If ann-in_vdef_list true,
then set build_loads before returning.
Index: tree-ssa-operands.c
===
--- tree-ssa-operands.c (revision 128394)
+++ tree-ssa-operands.c (working copy)
@@ -1164,8 +1164,15 @@
/* Don't allow duplicate entries. */
ann = get_var_ann (var);
- if (ann-in_vuse_list || ann-in_vdef_list)
+ if (ann-in_vuse_list)
return;
+ else if (ann-in_vdef_list)
+ {
+ /* We don't want a vuse if we already have a vdef, but we must
+still put this in build_loads. */
+ bitmap_set_bit (build_loads, DECL_UID (var));
+ return;
+ }
ann-in_vuse_list = true;
sym = var;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug ada/33392] ACATS cxa5a09, cxa5a10 and controlled2.adb failure
--- Comment #2 from anhvofrcaus at gmail dot com 2007-09-12 23:39 ---
Another problem, GNAT Bug Box, is resulted with the tree updated as shown
[...]
c-4.3-20070907/gcc/ada/a-chlat1.ads -o ada/a-chlat1.o
/home/voax/linux/build-4.3.x/./prev-gcc/xgcc
-B/home/voax/linux/build-4.3.x/./prev-gcc/ -B/usr/local/i686-pc-linux-gnu/bin/
-c -g -O2 -fomit-frame-pointer -gnatpg -gnata -g -O1 -fno-inline \
-nostdinc -I- -I. -Iada -I../../gcc-4.3-20070907/gcc/ada
../../gcc-4.3-20070907/gcc/ada/a-except.adb -o ada/a-except.o
+===GNAT BUG DETECTED==+
| 4.3.0 20070907 (experimental) (i686-pc-linux-gnu) Storage_Error stack
overflow (or erroneous memory access)|
| Error detected at a-except.adb:61:17 |
| 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). |
+==+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
compilation abandoned
make[3]: *** [ada/a-except.o] Error 1
make[3]: Leaving directory `/home/voax/linux/build-4.3.x/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/voax/linux/build-4.3.x'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/voax/linux/build-4.3.x'
make: *** [bootstrap] Error 2
AV
(In reply to comment #1)
cxa* tests have already been handled by Eric in latest sources.
controlled2.adb was a missing commit, also fixed yesterday.
So the solution is simply to update your tree.
Arno
(In reply to comment #0)
make: Entering directory `/home/voax/linux/build-4.3.x/gcc'
test -d testsuite/ada/acats || mkdir -p testsuite/ada/acats
testdir=`cd ../../gcc-4.3-20070907/gcc/testsuite/ada/acats; ${PWDCMD-pwd}`; \
export testdir; cd testsuite/ada/acats; /bin/sh ${testdir}/run_acats
=== acats configuration ===
target gcc is /home/voax/linux/build-4.3.x/gcc/xgcc
-B/home/voax/linux/build-4.3.x/gcc/
Reading specs from /home/voax/linux/build-4.3.x/gcc/specs Target:
i686-pc-linux-gnu Configured with: ../gcc-4.3-20070907/configure
--enable-languages=ada --with-mpfr=/home/voax/linux/tools/mpfr-2.2.1 Thread
model: posix gcc version 4.3.0 20070907 (experimental) (GCC)
host=i386-redhat-linux
target=i686-pc-linux-gnu
gnatmake is /home/voax/linux/build-4.3.x/gcc/gnatmake
=== acats support ===
Generating support files... done.
Compiling support files... done.
=== acats tests ===
Running chapter a ...
Running chapter c2 ...
Running chapter c3 ...
Running chapter c4 ...
Running chapter c5 ...
Running chapter c6 ...
Running chapter c7 ...
Running chapter c8 ...
Running chapter c9 ...
Running chapter ca ...
Running chapter cb ...
Running chapter cc ...
Running chapter cd ...
FAIL: cd92001
Running chapter ce ...
Running chapter cxa ...
FAIL: cxa5a09
FAIL: cxa5a10
Running chapter cxb ...
Running chapter cxf ...
Running chapter cxg ...
Running chapter cxh ...
FAIL: cxh1001
Running chapter cz ...
Running chapter d ...
Running chapter e ...
Running chapter gcc ...
Running chapter l ...
=== acats Summary ===
# of expected passes2311
# of unexpected failures4
*** FAILURES: cd92001 cxa5a09 cxa5a10 cxh1001
Making a new config file...
echo set tmpdir /home/voax/linux/build-4.3.x/gcc/testsuite ./tmp0
test -d testsuite || mkdir testsuite
test -d testsuite/gnat || mkdir testsuite/gnat
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd ../../gcc-4.3-20070907/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
cd testsuite/gnat; \
rm -f tmp-site.exp; \
sed '/set tmpdir/ s|testsuite|testsuite/gnat|' \
../../site.exp tmp-site.exp; \
/bin/sh ${srcdir}/../move-if-change tmp-site.exp site.exp; \
EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo
${rootme}/../expect/expect ; else echo expect ; fi` ; export EXPECT ; \
if [ -f ${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWDCMD-pwd}` ; \
export TCL_LIBRARY ; fi ; \
GCC_EXEC_PREFIX=/usr/local/lib/gcc/ ; export GCC_EXEC_PREFIX ; \
`if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo
${srcdir}/../dejagnu/runtest ; else echo runtest; fi` --tool gnat )
WARNING: Couldn't find the global config file.
Test Run By voax on Mon Sep 10 15:09:03 2007
Native configuration is i686-pc-linux-gnu
=== gnat tests ===
Schedule
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #23 from hjl at lucon dot org 2007-09-13 00:13 ---
(In reply to comment #22)
This works for the testcase, but has had no other testing as yet.
2007-09-12 James E. Wilson [EMAIL PROTECTED]
* tree-ssa-operands.c (append_vuse): If ann-in_vdef_list true,
then set build_loads before returning.
Index: tree-ssa-operands.c
===
--- tree-ssa-operands.c (revision 128394)
+++ tree-ssa-operands.c (working copy)
@@ -1164,8 +1164,15 @@
/* Don't allow duplicate entries. */
ann = get_var_ann (var);
- if (ann-in_vuse_list || ann-in_vdef_list)
+ if (ann-in_vuse_list)
return;
+ else if (ann-in_vdef_list)
+ {
+ /* We don't want a vuse if we already have a vdef, but we must
+still put this in build_loads. */
+ bitmap_set_bit (build_loads, DECL_UID (var));
+ return;
+ }
ann-in_vuse_list = true;
sym = var;
It works for C tests in libgomp. I am bootstrapping on Linux/ia64 now. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
[Bug testsuite/33153] FAIL: gcc.dg/pr32912-[12].c (test for excess errors)
--- Comment #5 from danglin at gcc dot gnu dot org 2007-09-13 00:43 --- Subject: Bug 33153 Author: danglin Date: Thu Sep 13 00:43:04 2007 New Revision: 128454 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128454 Log: PR testsuite/33153 * gcc.dg/pr32912-1.c: Add -fno-common to options on hppa*-*-hpux*. * gcc.dg/pr32912-2.c: Delete declaration of a, b, c, d, e and f. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr32912-1.c trunk/gcc/testsuite/gcc.dg/pr32912-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33153
[Bug c++/33414] New: [4.3 regression] segfault
seen with 4.3 20070909, works with 4.2 20070831 Matthias $ g++ -c -O2 -g -fPIC -c libkformulalib_la.all_cc.iiIn file included from libkformulalib_la.all_cc.cc:45:/scratch/packages/lpia/tmp/koffice-1.6.3/./lib/kformula/formulacursor.cc: In member function 'KFormula::BasicElement* KFormula::FormulaCursor::getSelectedChild()':/scratch/packages/lpia/tmp/koffice-1.6.3/./lib/kformula/formulacursor.cc:462: internal compiler error: Segmentation faultPlease submit a full bug report,with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: [4.3 regression] segfault Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33414
[Bug c++/33414] [4.3 regression] segfault
--- Comment #1 from debian-gcc at lists dot debian dot org 2007-09-13 00:59 --- Created an attachment (id=14199) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14199action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33414
[Bug testsuite/33153] FAIL: gcc.dg/pr32912-[12].c (test for excess errors)
--- Comment #6 from danglin at gcc dot gnu dot org 2007-09-13 03:45 --- Subject: Bug 33153 Author: danglin Date: Thu Sep 13 03:45:16 2007 New Revision: 128456 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128456 Log: PR testsuite/33153 * gcc.dg/pr32912-1.c: Add -fno-common to options on hppa*-*-hpux*. * gcc.dg/pr32912-2.c: Delete declaration of a, b, c, d, e and f. Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/pr32912-1.c branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/pr32912-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33153
[Bug target/33406] [4.3 Regression] At revision 128385 Bootstraping PPC Darwin still fail in Java
--- Comment #5 from andreast at gcc dot gnu dot org 2007-09-13 03:56 --- I see now the same, --enable-checking is used now. -- andreast at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-13 03:56:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33406
[Bug testsuite/33153] FAIL: gcc.dg/pr32912-[12].c (test for excess errors)
--- Comment #7 from danglin at gcc dot gnu dot org 2007-09-13 03:49 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33153
[Bug tree-optimization/33389] [4.3 Regression] Revision 128239 causes libgomp failure
--- Comment #24 from hjl at lucon dot org 2007-09-13 04:03 --- (In reply to comment #23) (In reply to comment #22) 2007-09-12 James E. Wilson [EMAIL PROTECTED] * tree-ssa-operands.c (append_vuse): If ann-in_vdef_list true, then set build_loads before returning. It works for C tests in libgomp. I am bootstrapping on Linux/ia64 now. Thanks. It seems fine on Linux/ia64, Linux/ia32 and Linux/x86-64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
