[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-20 06:21:27 UTC --- This is due to revision 165973: Author:janus Date:Tue Oct 26 17:38:42 2010 UTC (7 months, 3 weeks ago) Changed paths:10 Log Message: 2010-10-26 Janus Weil ja...@gcc.gnu.org PR fortran/42647 * trans.h (gfc_deallocate_scalar_with_status): New prototype. * trans.c (gfc_deallocate_scalar_with_status): New function for deallocation of allocatable scalars. * trans-array.c (structure_alloc_comps): Call it here ... * trans-decl.c (gfc_trans_deferred_vars): ... here ... * trans-stmt.c (gfc_trans_deallocate): ... and here. 2010-10-26 Janus Weil ja...@gcc.gnu.org PR fortran/42647 * gfortran.dg/allocatable_scalar_9.f90: Extended. * gfortran.dg/allocatable_scalar_10.f90: New. * gfortran.dg/class_19.f03: Extended. Another test: program evolve_aflow implicit none type :: state_t real, allocatable :: U(:) end type state_t type, extends(state_t) :: astate_t end type astate_t type(astate_t) :: a,b allocate(a%U(1000)) allocate(b%U(1000)) ! b%U = a%U a = b deallocate(a%U, b%U) end program
[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787 --- Comment #24 from Thomas Henlich thenlich at users dot sourceforge.net 2011-06-20 07:15:19 UTC --- (In reply to comment #22) This is kind of bad: print (RU,F7.0), 7500.0 ! 8. expected 7500. print (RD,F7.0), -7500.0 ! -8. expected -7500. I've traced the bug down to this code: http://gcc.gnu.org/viewcvs/trunk/libgfortran/io/write_float.def?r1=173231r2=173408pathrev=173408 + rchar = '0'; + if (w 0 d == 0 p == 0) +nbefore = 1; + /* Scan for trailing zeros to see if we really need to round it. */ which I don't understand. Why are we setting the number of digits before the decimal point to 1 if the width is zero and the scale factor is zero and the number of requested digits after the decimal point is zero?
[Bug tree-optimization/49471] New: ICE when -ftree-parallelize-loops is enabled together with -m32 on power7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49471
Summary: ICE when -ftree-parallelize-loops is enabled together
with -m32 on power7
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ra...@il.ibm.com
When building cactusADM on igoo, I get an error when autopar is enabled with
-m32
(does not happen for 64!)
This is the command line which is executed:
/home/razya/gcc-bin/bin/gcc -c -o PUGHReduce/ReductionNormInf.o -DSPEC_CPU
-DNDEBUG -Iinclude -I../include -DCCODE -m32 -ffast-math -O3
-fno-tree-vectorize -fno-vect-cost-model -ftree-parallelize-loops=6
PUGHReduce/ReductionNormInf.c
The source of the failure is at the code generated to expand omp_for pragma (in
tree level).
The expansion of pragma omp_for generates a prolog code which calculates the
particular interval of (the loop's) iterations which the thread (executing
this code) should execute.
This prolog calculation involves some arithmetic operations, and in particular
MULT and DIV statements which cause the failures.
so, for example, this is the tree level code generated for the prolog, and the
div and mult operations highlighted in red:
D.7313_5 = MEM[(struct *).paral_data_param_1(D)].D.7288; /* Number of loop
iterations. */
D.7316_8 = __builtin_omp_get_num_threads ();
D.7317_9 = (unnamed-unsigned:128) D.7316_8;
D.7318_10 = __builtin_omp_get_thread_num ();
D.7319_11 = (unnamed-unsigned:128) D.7318_10;
D.7320_12 = D.7313_5 / D.7317_9;
D.7321_13 = D.7320_12 * D.7317_9;
D.7322_14 = D.7321_13 != D.7313_5;
D.7323_15 = D.7322_14 + D.7320_12;
ivtmp.575_16 = D.7323_15 * D.7319_11;
D.7325_17 = ivtmp.575_16 + D.7323_15;
D.7326_18 = MIN_EXPR D.7325_17, D.7313_5;
if (ivtmp.575_16 = D.7326_18)
goto bb 3;
else
goto bb 4;
when the div expr is being expanded to RTL code, we fail in executing
the following expand_binop:
expmed.c:
quotient = sign_expand_binop (compute_mode,
udiv_optab, sdiv_optab,
op0, op1, target,
unsignedp, OPTAB_LIB_WIDEN);
The call to this function returns NULL (where it shouldn't s far as I
understand).
When I tried removing the div instruction, the mult expr caused an assert
failure
in expand_mult() because the following call returned NULL.:
expmed.c:
/* This used to use umul_optab if unsigned, but for non-widening multiply
there is no difference between signed and unsigned. */
op0 = expand_binop (mode,
! unsignedp
flag_trapv (GET_MODE_CLASS(mode) == MODE_INT)
? smulv_optab : smul_optab,
op0, op1, target, unsignedp, OPTAB_LIB_WIDEN);
gcc_assert (op0);
---
I found that the variables being divided/multiplied are of 128 bit types.
They are created when canonicalize_loop_ivs is called:
tree
canonicalize_loop_ivs (struct loop *loop, tree *nit, bool bump_in_latch)
{
unsigned precision = TYPE_PRECISION (TREE_TYPE (*nit)); //precision of
number of iterations
for (psi = gsi_start_phis (loop-header);
!gsi_end_p (psi); gsi_next (psi))
{
gimple phi = gsi_stmt (psi);
tree res = PHI_RESULT (phi);
if (is_gimple_reg (res) TYPE_PRECISION (TREE_TYPE (res)) precision)
precision = TYPE_PRECISION (TREE_TYPE (res));
}
type = lang_hooks.types.type_for_size (precision, 1);// here precision is
128
}
Note that this is also the case when -m64 is enabled.
The difference is that the type created by lang_hooks for the -m32 case is
unnamed-unsigned:128
and for -m64 it is __int128 unsigned, whose arithmetic operations apparently
are handled correctly by the compiler.
[Bug rtl-optimization/44194] struct returned by value generates useless stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194 --- Comment #32 from rguenther at suse dot de rguenther at suse dot de 2011-06-20 09:22:31 UTC --- On Sat, 18 Jun 2011, xinliangli at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194 --- Comment #29 from davidxl xinliangli at gmail dot com 2011-06-18 09:05:10 UTC --- Is Easwaran's patch a reasonable way to go? The approach looks reasonable (with create_tmp_var instead of _reg), whether it is ok in the calls.c context I didn't look at. Richard.
[Bug c/49467] Enhancement: Intrinsic to read CARRY and OVERFLOW flags (where applicable)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49467 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Joseph S. Myers jsm28 at gcc dot gnu.org 2011-06-20 09:46:59 UTC --- The proposed interface, with its references to global flags set by operations that otherwise have values but no side effects, is not a good match to the nature of C as a high-level language; the source code arithmetic operations should not be presumed to have any particular correspondence to machine instructions that might set flags. Instead, I proposed a more appropriate interface for operations with explicit overflow behavior in bug 48580. *** This bug has been marked as a duplicate of bug 48580 ***
[Bug middle-end/48580] missed optimization: integer overflow checks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added CC||noloader at gmail dot com --- Comment #11 from Joseph S. Myers jsm28 at gcc dot gnu.org 2011-06-20 09:46:59 UTC --- *** Bug 49467 has been marked as a duplicate of this bug. ***
[Bug c++/49470] no matching constructor for initialization errors not detected in g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49470 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-20 10:06:13 UTC --- If you instantiate the template you get an error. There are LOTS of things clang diagnoses in uninstantiated templates that g++ doesn't
[Bug middle-end/49465] [4.7 Regression] Revision 175114 miscompiled 403.gcc in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49465 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug tree-optimization/49471] ICE when -ftree-parallelize-loops is enabled together with -m32 on power7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49471 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-20 10:22:52 UTC --- Why is D.7313_5 = MEM[(struct *).paral_data_param_1(D)].D.7288; /* Number of loop iterations. */ of type __int128? That looks bogus.
[Bug middle-end/49463] [4.7 Regression] LTO testcase failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49463 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/49470] no matching constructor for initialization errors not detected in g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49470 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Severity|normal |enhancement --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-20 10:26:56 UTC --- The summary isn't very relevant, the problem has nothing to do with constructors, it's just that g++ doesn't check before instantiation whether no valid specialization can be formed for a template. 14.6 [temp.res] p7: If no valid specialization can be generated for a template definition, and that template is not instantiated, the template definition is ill-formed, no diagnostic required. ... [ Note: If a template is instantiated, errors will be diagnosed according to the other rules in this Standard. Exactly when these errors are diagnosed is a quality of implementation issue. —end note ]
[Bug tree-optimization/49460] g++: Internal error: Segmentation fault (program cc1plus) using -O2 or -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49460
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.06.20 10:42:56
Component|c++ |tree-optimization
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-20
10:42:56 UTC ---
Confirmed. Other workaround: -fno-tree-pre.
We are endlessly translating
{component_reffNextCell,indirect_ref,D.126308_166}@.MEM_238
[Bug target/49446] avr-g++ does not optimize when using bitshift in inlined function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49446 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-06-20 10:50:27 UTC --- This issue is similar to PR33049 and con be caught by implementing extzv pattern. *** This bug has been marked as a duplicate of bug 33049 ***
[Bug target/33049] [avr] bit extraction non optimal, inversing logic solves problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33049 --- Comment #16 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-06-20 10:50:27 UTC --- *** Bug 49446 has been marked as a duplicate of this bug. ***
[Bug target/33049] [avr] bit extraction non optimal, inversing logic solves problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33049 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |gjl at gcc dot gnu.org |gnu.org | --- Comment #17 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-06-20 10:58:59 UTC --- Created attachment 24563 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24563 pr33049.diff Patch also covering PR49446. Tested without regression against SVN 175201 PR target/33049 * config/avr/avr.md (extzv): New expander. (*extzv, *extzv.qihi1, *extzv.qihi2): New insn-and-split.
[Bug target/33049] [avr] bit extraction non optimal, inversing logic solves problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33049 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug testsuite/49464] [4.6/4.7 Regression] FAIL: g++.dg/ext/altivec-17.C (test for errors, line 15)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49464
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.06.20 11:00:17
Summary|[4.7 Regression] FAIL: |[4.6/4.7 Regression] FAIL:
|g++.dg/ext/altivec-17.C |g++.dg/ext/altivec-17.C
|(test for errors, line 15) |(test for errors, line 15)
Ever Confirmed|0 |1
--- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-20
11:00:17 UTC ---
What would be the best fix between the two?
--- /opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/ext/altivec-17.C2010-07-08
10:41:46.0 +0200
+++ /opt/gcc/work/gcc/testsuite/g++.dg/ext/altivec-17.C2011-06-20
12:46:32.0 +0200
@@ -12,5 +12,5 @@ typedef vector__ bool__ int bool_simd_ty
void Foo (bool_simd_type const a)
{
- simd_type const v = a; // { dg-error 'const simd_type' from expression of
type 'const bool_simd_type' }
+ simd_type const v = a; // { dg-error 'const simd_type {aka \[^\n\r\}\]*}'
from expression of type 'const bool_simd_type {aka \[^\n\r\}\]*}' }
}
or
--- /opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/ext/altivec-17.C2010-07-08
10:41:46.0 +0200
+++ /Users/dominiq/Desktop/altivec-17.C2011-06-20 12:01:18.0 +0200
@@ -12,5 +12,5 @@ typedef vector__ bool__ int bool_simd_ty
void Foo (bool_simd_type const a)
{
- simd_type const v = a; // { dg-error 'const simd_type' from expression of
type 'const bool_simd_type' }
+ simd_type const v = a; // { dg-error 'const simd_type {aka const
__vector\\\(4\\\) unsigned int}' from expression of type 'const bool_simd_type
{aka const __vector\\\(4\\\) __bool int}' }
}
[Bug fortran/49472] New: [gfortran, 4.7 regression] Compiler segfault on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49472 Summary: [gfortran, 4.7 regression] Compiler segfault on valid code Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@mpa-garching.mpg.de When trying to compile the code below with gfortran 4.7 and a specific set of flags, the compiler segfaults: /scratch/martin/tmp/planck/lscleangfortran -v -g -O -ffast-math -c CAMB/modules.f90 Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/afs/mpa/data/martin/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /scratch/martin/gcc/configure --disable-bootstrap --disable-graphite --enable-gold --enable-plugins --prefix=/afs/mpa/data/martin/ugcc --with-libelf=/afs/mpa/data/martin/numlibs64 --enable-languages=c++,fortran --enable-target=all --enable-checking=release Thread model: posix gcc version 4.7.0 20110620 (experimental) [trunk revision 175202] (GCC) COLLECT_GCC_OPTIONS='-v' '-g' '-O' '-ffast-math' '-c' '-mtune=generic' '-march=x86-64' /afs/mpa/data/martin/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/f951 CAMB/modules.f90 -quiet -dumpbase modules.f90 -mtune=generic -march=x86-64 -auxbase modules -g -O -version -ffast-math -fintrinsic-modules-path /afs/mpa/data/martin/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/finclude -o /tmp/ccHb3jKV.s GNU Fortran (GCC) version 4.7.0 20110620 (experimental) [trunk revision 175202] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.2, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran (GCC) version 4.7.0 20110620 (experimental) [trunk revision 175202] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.2, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 gfortran: internal compiler error: Segmentation fault (program f951) Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The code compiles without complaint with gfortran 4.5.2 and the head of the 4.6 branch. module MassiveNu implicit none private integer, parameter :: dl = KIND(1.d0) real(dl), dimension(:), allocatable :: r1,p1,dr1,dp1,ddr1,qdn real(dl), parameter :: dq=1._dl integer, parameter :: nqmax0=15 !number of q to sample for each l integer nqmax contains subroutine Nu_derivs(am,adotoa,rhonu,rhonudot,shearnudot,psi2,psi2dot) real(dl) psi2(nqmax0),psi2dot(nqmax0) real(dl) g1(nqmax0+1) real(dl) adotoa,rhonu,rhonudot,shearnudot real(dl) aq,q,v,d,aqdot,vdot,g0 real(dl), intent(IN) :: am integer iq do iq=2,(nqmax0+1) q=(iq-1.5d0)*dq aq=am/q aqdot=aq*adotoa v=1._dl/sqrt(1._dl+aq*aq) vdot=-aq*aqdot/(1._dl+aq*aq)**1.5d0 g1(iq)=qdn(iq-1)*(psi2dot(iq-1)*v+psi2(iq-1)*vdot) end do call splint(g1,g0,nqmax0+1) end subroutine Nu_derivs end module MassiveNu
[Bug target/49423] [arm] internal compiler error: in push_minipool_fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2011-06-20 11:10:11 UTC --- I can reproduce the ICE on armv5tel-linux-gnueabi with gcc-4.6.0 and 4.6-20110617, but not with gcc-4.5.3 or the latest 4.7 snapshot. The ICE stopped occurring on trunk with r170984 (PR41490 fix). However that's a generic missed-optimization fix, so I suspect the bug is latent on trunk.
[Bug target/48454] gfortran.dg/char_result_13.f90 fails with -O3 -funroll-loops -mvectorize-with-neon-quad
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48454 --- Comment #7 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-06-20 11:14:54 UTC --- Author: ramana Date: Mon Jun 20 11:14:50 2011 New Revision: 175205 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175205 Log: 2011-06-20 Ramana Radhakrishnan ramana.radhakrish...@linaro.org Backport from mainline. 2011-06-13 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR target/48454 * config/arm/neon.md (vec_pack_trunc): Set the lengths correctly for the case with Quad vectors. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/arm/neon.md
[Bug libmudflap/38738] libmudflap could be enabled for Solaris when using GNU ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38738 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.20 11:23:10 CC||ro at gcc dot gnu.org AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #5 from Rainer Orth ro at gcc dot gnu.org 2011-06-20 11:23:10 UTC --- It doesn't even depend on GNU ld, though: newer versions of Sun ld support --wrap (resp. -z wrap), too. I'm working to get this fixed. Rainer
[Bug fortran/49472] [gfortran, 4.7 regression] Compiler segfault on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49472 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.20 11:31:25 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-20 11:31:25 UTC --- Revision 174379 is OK, 174487 is not. GDB shows Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x7fff5bc00ef8 0x00010075c6f6 in simplify_binary_operation (code=MULT, mode=DFmode, op0=0x141f29e10, op1=0x141f29438) at ../../work/gcc/simplify-rtx.c:1842 1842 swap_commutative_operands_p (op0, op1))
[Bug target/49473] New: [arm] poor scheduling of loads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49473
Summary: [arm] poor scheduling of loads
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ph...@gnu.org
Target: arm-linux
The instruction scheduler doesn't seem to be doing a very good job of
accounting for the load delay slots on ARM1136JF-S. See for example the
attached testcase:
$ ./cc1 -fPIC -O2 -mtune=arm1136jf-s -march=armv6 -mfpu=vfp -mfloat-abi=soft
which yields:
gst_mpegts_demux_sink_setcaps:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
stmfdsp!, {r4, r5, r6, r7, r8, lr}
subsp, sp, #16
movr7, r1
blgst_object_get_parent(PLT)
movr1, #0
ldrr4, .L7
.LPIC0:
addr4, pc, r4
movr5, r0
movr0, r7
blgst_caps_get_structure(PLT)
ldrr3, .L7+4
ldrr6, [r4, r3]
ldrr3, [r6, #0]
cmpr3, #3
movr8, r0
bls.L5
ldrr3, .L7+8
ldrr1, .L7+12
.LPIC2:
addr3, pc, r3
addr2, r3, #64
stmiasp, {r1, r5}
strr2, [sp, #8]
strr7, [sp, #12]
addr2, r3, #12
movr0, #0
movr1, #4
addr3, r3, #32
blgst_debug_log(PLT)
.L5:
ldrr4, .L7+16
addr2, r5, #32768
.LPIC1:
addr4, pc, r4
movr0, r8
movr1, r4
addr2, r2, #172
blgst_structure_get_int(PLT)
cmpr0, #0
bne.L3
ldrr3, [r6, #0]
cmpr3, #3
bls.L3
movr2, #484
addr3, r4, #88
stmiasp, {r2, r5}
strr3, [sp, #8]
movr1, #4
addr2, r4, #12
addr3, r4, #32
blgst_debug_log(PLT)
.L3:
movr0, r5
blgst_object_unref(PLT)
movr0, #1
addsp, sp, #16
ldmfdsp!, {r4, r5, r6, r7, r8, pc}
Note that:
- the add at .LPIC0 will stall for two cycles because the preceding load has a
result latency of three. The two subsequent MOVs could have been scheduled in
these slots since they don't have any data dependency on the ADD;
- the add at .LPIC1 will stall for one cycle for the same reason, and the same
applies to the following MOV.
On this topic I noticed that arm1136jfs.md has:
;; An alu op can start sooner after a load, if that alu op does not
;; have an early register dependency on the load
(define_bypass 2 11_load1
11_alu_op)
(define_bypass 2 11_load1
11_alu_shift_op
arm_no_early_alu_shift_value_dep)
(define_bypass 2 11_load1
11_alu_shift_reg_op
arm_no_early_alu_shift_dep)
... which seems a little strange, since the result latency of LDR is three not
two according to the documentation. The above bypasses look like they would be
correct for instructions where the dependency is a Late Reg, but that isn't the
case for alu_ops.
[Bug target/49473] [arm] poor scheduling of loads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49473 --- Comment #1 from philb at gnu dot org 2011-06-20 11:43:48 UTC --- Created attachment 24564 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24564 testcase
[Bug libmudflap/38738] libmudflap could be enabled for Solaris when using GNU ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38738 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-06/msg01446.htm ||l --- Comment #6 from Rainer Orth ro at gcc dot gnu.org 2011-06-20 11:47:05 UTC --- Initial patch posted.
[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43603 --- Comment #25 from Andrey Belevantsev abel at gcc dot gnu.org 2011-06-20 11:56:11 UTC --- Author: abel Date: Mon Jun 20 11:56:08 2011 New Revision: 175207 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175207 Log: Backport from mainline 2010-12-07 Andrey Belevantsev a...@ispras.ru PR target/43603 * haifa-sched.c (sched_create_recovery_edges): Update dominator info. * sel-sched-ir.c (maybe_tidy_empty_bb): Update dominator info after deleting an empty block, verify dominators. (sel_remove_bb): Update dominator info after removing a block. (sel_redirect_edge_and_branch_force): Assert that no unreachable blocks will be created. Update dominator info. (sel_redirect_edge_and_branch): Update dominator info when basic blocks do not become unreachable. (sel_remove_loop_preheader): Update dominator info. 2010-10-14 Andrey Belevantsev a...@ispras.ru * sel-sched-ir.c (maybe_tidy_empty_bb): Simplify comment. (tidy_control_flow): Tidy vertical space. (sel_remove_bb): New variable idx. Use it to remember the basic block index before deleting the block. (sel_remove_empty_bb): Remove dead code, simplify and insert to ... (sel_merge_blocks): ... here. Add forward declaration. * sel-sched-ir.h (sel_remove_empty_bb): Remove prototype. (sel_merge_blocks): Likewise. 2011-06-20 Andrey Belevantsev a...@ispras.ru Backport from mainline 2010-12-07 Andrey Belevantsev a...@ispras.ru PR target/43603 * gcc.target/ia64/pr43603.c: New. * gcc/testsuite/g++.dg/opt/pr46640.C: New. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/opt/pr46640.C branches/gcc-4_4-branch/gcc/testsuite/gcc.target/ia64/pr43603.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/haifa-sched.c branches/gcc-4_4-branch/gcc/sel-sched-ir.c branches/gcc-4_4-branch/gcc/sel-sched-ir.h branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/49472] [4.7 regression] Compiler segfault on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49472 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|fortran |rtl-optimization Target Milestone|--- |4.7.0 Summary|[gfortran, 4.7 regression] |[4.7 regression] Compiler |Compiler segfault on valid |segfault on valid code |code| --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-20 11:54:44 UTC --- We endlessly recurse simplifying from fwprop #20152 0x01169de1 in propagate_rtx_1 (px=0x7fffd940, old_rtx=0x75b3f7a0, new_rtx=0x75b48ba0, flags=6) at /space/rguenther/src/svn/trunk/gcc/fwprop.c:507 507 tem = simplify_gen_binary (code, mode, op0, op1); (gdb) down #20151 0x00b0f51e in simplify_gen_binary (code=MULT, mode=DFmode, op0=0x75b48bd0, op1=0x75b48ba0) at /space/rguenther/src/svn/trunk/gcc/simplify-rtx.c:117 117 tem = simplify_binary_operation (code, mode, op0, op1); (gdb) call debug_rtx (op0) (mult:DF (mult:DF (div:DF (reg:DF 80 [ D.1612 ]) (reg:DF 123)) (neg:DF (div:DF (const_double:DF 1.0e+0 [0x0.8p+1]) (reg:DF 103 [ powroot.4 ] (reg:DF 82 [ D.1613 ])) (gdb) call debug_rtx (op1) (div:DF (reg:DF 80 [ D.1612 ]) (reg:DF 123))
[Bug target/43603] gcc-4.4.3 ICE on ia64 with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43603 --- Comment #26 from devurandom at gmx dot net 2011-06-20 12:09:26 UTC --- Thanks a lot!
[Bug rtl-optimization/49472] [4.7 regression] Compiler segfault on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49472 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #3 from janus at gcc dot gnu.org 2011-06-20 12:12:31 UTC --- Slightly reduced test case: module MassiveNu implicit none contains subroutine Nu_derivs integer, parameter :: dl = KIND(1.d0) integer, parameter :: nqmax0 = 3 real(dl) :: adotoa,aq,aqdot,vdot, g1(nqmax0+1) integer :: iq do iq=2,(nqmax0+1) aq=1./((iq-1.5d0)*1.) aqdot=aq*adotoa vdot=-aq*aqdot/(1.+aq*aq)**1.5d0 g1(iq)=vdot end do call dummy(g1) end subroutine end module This fails with Program received signal SIGSEGV, Segmentation fault. 0x00b27430 in simplify_const_unary_operation (code=Cannot access memory at address 0x7f7fefec) at /home/jweil/gcc47/trunk/gcc/simplify-rtx.c:1212
[Bug target/49385] Invalid RTL intstruction for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49385 --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-06-20 12:16:04 UTC --- Author: ramana Date: Mon Jun 20 12:15:58 2011 New Revision: 175208 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175208 Log: Fix PR target/49385 2011-06-20 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR target/49385 * config/arm/thumb2.md (*thumb2_movhi_insn): Make sure atleast one of the operands is a register. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/thumb2.md
[Bug tree-optimization/49471] ICE when -ftree-parallelize-loops is enabled together with -m32 on power7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49471
--- Comment #2 from razya at il dot ibm.com 2011-06-20 12:31:32 UTC ---
(In reply to comment #1)
Why is
D.7313_5 = MEM[(struct *).paral_data_param_1(D)].D.7288; /* Number of loop
iterations. */
of type __int128? That looks bogus.
the size of 128 was determined according to the precision of the ivs in
canonicalize_loop_ivs:
canonicalize_loop_ivs (struct loop *loop, tree *nit, bool bump_in_latch)
{
unsigned precision = TYPE_PRECISION (TREE_TYPE (*nit));
for (psi = gsi_start_phis (loop-header);
!gsi_end_p (psi); gsi_next (psi))
{
gimple phi = gsi_stmt (psi);
tree res = PHI_RESULT (phi);
if (is_gimple_reg (res) TYPE_PRECISION (TREE_TYPE (res)) precision)
precision = TYPE_PRECISION (TREE_TYPE (res));
}
type = lang_hooks.types.type_for_size (precision, 1); // precision == 128
...
}
Does it seem that the precision should not determine the new type size, or that
the precision itself being 128 is strange?
[Bug tree-optimization/49460] g++: Internal error: Segmentation fault (program cc1plus) using -O2 or -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49460 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-20 12:53:53 UTC --- Created attachment 24565 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24565 autoreduced testcase
[Bug tree-optimization/49471] ICE when -ftree-parallelize-loops is enabled together with -m32 on power7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49471
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-20
12:55:10 UTC ---
(In reply to comment #2)
(In reply to comment #1)
Why is
D.7313_5 = MEM[(struct *).paral_data_param_1(D)].D.7288; /* Number of
loop
iterations. */
of type __int128? That looks bogus.
the size of 128 was determined according to the precision of the ivs in
canonicalize_loop_ivs:
canonicalize_loop_ivs (struct loop *loop, tree *nit, bool bump_in_latch)
{
unsigned precision = TYPE_PRECISION (TREE_TYPE (*nit));
for (psi = gsi_start_phis (loop-header);
!gsi_end_p (psi); gsi_next (psi))
{
gimple phi = gsi_stmt (psi);
tree res = PHI_RESULT (phi);
if (is_gimple_reg (res) TYPE_PRECISION (TREE_TYPE (res)) precision)
precision = TYPE_PRECISION (TREE_TYPE (res));
}
type = lang_hooks.types.type_for_size (precision, 1); // precision == 128
...
}
Does it seem that the precision should not determine the new type size, or
that
the precision itself being 128 is strange?
Well, autopar seems to introduce this 128 bit type in the first place,
and I wonder why it does that. And it definitely should avoid doing this.
[Bug middle-end/48016] Inconsistency in non-local goto save area
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48016 --- Comment #6 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-06-20 13:58:03 UTC --- Author: hjl Date: Mon Jun 20 13:57:59 2011 New Revision: 175210 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175210 Log: Use proper mode for stack save area. 2011-06-15 H.J. Lu hongjiu...@intel.com PR middle-end/48016 * explow.c (emit_stack_save): Don'ty adjust mode of stack save area. (update_nonlocal_goto_save_area): Use proper mode for stack save area. Modified: branches/x32/gcc/ChangeLog.x32 branches/x32/gcc/explow.c
[Bug rtl-optimization/49472] [4.7 regression] Compiler segfault on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49472 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-20 14:12:26 UTC --- This pr has been introduced by revision 174446 Author:wschmidt Date:Mon May 30 17:12:53 2011 UTC (2 weeks, 6 days ago) Changed paths:2 Log Message: 2011-05-30 Bill Schmidt wschm...@linux.vnet.ibm.com PR tree-optimization/46728 * tree-ssa-math-opts.c (build_and_insert_call): Reorder parms. (build_and_insert_binop): New. (gimple_expand_builtin_pow): Reorder args for build_and_insert_call; use build_and_insert_binop; add more optimizations for fractional exponents. The minimal set of options is '-O1 -ffast-math -g'.
[Bug tree-optimization/49471] ICE when -ftree-parallelize-loops is enabled together with -m32 on power7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49471
--- Comment #4 from razya at il dot ibm.com 2011-06-20 14:14:13 UTC ---
(In reply to comment #3)
(In reply to comment #2)
(In reply to comment #1)
Why is
D.7313_5 = MEM[(struct *).paral_data_param_1(D)].D.7288; /* Number of
loop
iterations. */
of type __int128? That looks bogus.
the size of 128 was determined according to the precision of the ivs in
canonicalize_loop_ivs:
canonicalize_loop_ivs (struct loop *loop, tree *nit, bool bump_in_latch)
{
unsigned precision = TYPE_PRECISION (TREE_TYPE (*nit));
for (psi = gsi_start_phis (loop-header);
!gsi_end_p (psi); gsi_next (psi))
{
gimple phi = gsi_stmt (psi);
tree res = PHI_RESULT (phi);
if (is_gimple_reg (res) TYPE_PRECISION (TREE_TYPE (res))
precision)
precision = TYPE_PRECISION (TREE_TYPE (res));
}
type = lang_hooks.types.type_for_size (precision, 1); // precision == 128
...
}
Does it seem that the precision should not determine the new type size, or
that
the precision itself being 128 is strange?
Well, autopar seems to introduce this 128 bit type in the first place,
and I wonder why it does that. And it definitely should avoid doing this.
What happens is that autopar calls canonicalize_loop_ivs() when it is starting
to change the loop.
Here's a part of the documentation of canonicalize_loop_ivs():
When the IV type precision has to be larger
than *NIT type precision, *NIT is converted to the larger type, the
conversion code is inserted before the loop, and *NIT is updated to
the new definition.
In this case of cactusADM, one of the loop's IVs indeed has a precision of 128,
and therefore a conversion to a type of 128 bit is created.
I checked the precision of the loop's IVs a few passes before autopar, and even
when I disable autopar, and indeed there is an IV that has a type with 128
precision.
[Bug rtl-optimization/49472] [4.7 regression] Compiler segfault on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49472 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-20 14:17:51 UTC --- The test in comment #3 compiles if I replace (1._dl+aq*aq)**1.5d0 with sqrt((1._dl+aq*aq)**3).
[Bug libgcj/49314] md5test, shatest output FAILs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49314 --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-06-20 14:30:11 UTC --- Does http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01375.html have any impact on this bug? No, as I said, the md5test and shatest executables are correctly linked with libiconv.so and the system library is indeed present in the program. Rainer
[Bug libfortran/49296] [4.6/4.7 Regression] Wrong END OF FILE error for list-directed I/O with strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49296 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.6.1 |4.6.2 --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-20 14:32:27 UTC --- Missed GCC 4.6.1 (RC was just posted), should thus be fixed for 4.6.2 when the branch opens again. Cf. http://gcc.gnu.org/ml/gcc/2011-06/msg00274.html
[Bug target/49385] Invalid RTL intstruction for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49385 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ramana at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-06-20 14:34:07 UTC --- Fixed now. ramana
[Bug c++/43831] [C++0x] gcc-4.5.0 does not fail invalid lambda captures (against n3092 5.1.2/8)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43831 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-06-20 14:39:48 UTC --- Author: jason Date: Mon Jun 20 14:39:44 2011 New Revision: 175211 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175211 Log: PR c++/43831 * parser.c (cp_parser_lambda_introducer): Complain about redundant captures. * semantics.c (add_capture): Likewise. (register_capture_members): Clear IDENTIFIER_MARKED. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-capture-redundancy.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/43321] [c++0x] ICE on valid auto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43321 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-06-20 14:39:56 UTC --- Author: jason Date: Mon Jun 20 14:39:53 2011 New Revision: 175212 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175212 Log: PR c++/43321 * semantics.c (describable_type): Remove. * cp-tree.h: Likewise. * decl.c (cp_finish_decl): Don't call it. * init.c (build_new): Likewise. * parser.c (cp_parser_omp_for_loop): Likewise. * pt.c (tsubst_decl): Likewise. (do_auto_deduction): If we fail in a template, try again at instantiation time. Added: trunk/gcc/testsuite/g++.dg/cpp0x/auto26.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/init.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c++/49205] [C++0x] Default constructor with pack expansion parameter not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49205 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2011-06-20 14:40:15 UTC --- Author: jason Date: Mon Jun 20 14:40:10 2011 New Revision: 175214 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175214 Log: PR c++/49205 * call.c (sufficient_parms_p): Allow parameter packs too. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic-default.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug c++/37089] [C++0x] rvalue/lvalue reference collapsing not performed in error ouput thus printing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37089 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-06-20 14:40:05 UTC --- Author: jason Date: Mon Jun 20 14:40:01 2011 New Revision: 175213 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175213 Log: PR c++/37089 * cp-demangle.c (d_print_comp): Handle reference smashing. Modified: trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/testsuite/demangle-expected
[Bug c++/48138] __attribute__((aligned)) should give an error when applied to a typedef or template parameter, at least in C++0x mode.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48138 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-06-20 14:40:27 UTC --- Author: jason Date: Mon Jun 20 14:40:19 2011 New Revision: 175215 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175215 Log: PR c++/48138 * tree.c (strip_typedefs): Use build_aligned_type. Added: trunk/gcc/testsuite/g++.dg/ext/attr-aligned01.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog
[Bug c++/47080] [C++0x] explicit conversion function return conversions not restricted to qualifications
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47080 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-06-20 14:40:43 UTC --- Author: jason Date: Mon Jun 20 14:40:38 2011 New Revision: 175217 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175217 Log: PR c++/47080 * call.c (rejection_reason_code): Add rr_explicit_conversion. (print_z_candidate): Handle it. (explicit_conversion_rejection): New. (build_user_type_conversion_1): Reject an explicit conversion function that requires more than a qualification conversion. Added: trunk/gcc/testsuite/g++.dg/cpp0x/explicit6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug c++/47080] [C++0x] explicit conversion function return conversions not restricted to qualifications
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47080 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-06-20 14:44:15 UTC --- Fixed for 4.7.0.
[Bug c++/49205] [C++0x] Default constructor with pack expansion parameter not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49205 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-06-20 14:43:23 UTC --- (In reply to comment #1) While this behavior is erroneous, consensus at clang was that WG21 made an oversight in allowing this. Template constructors are banned from being copy or move constructors, and historically this prohibition was not necessary for default constructors since there was no special handling of them except when implicit. I disagree with this. As Johannes points out, it is possible to have a template default constructor in C++03, so changing this would be a significant change. We should just treat the variadic template as a default constructor.
[Bug c++/47635] [C++0x] ICE on invalid code in constructor_name_p, at cp/name-lookup.c:1809
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47635 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2011-06-20 14:40:34 UTC --- Author: jason Date: Mon Jun 20 14:40:29 2011 New Revision: 175216 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175216 Log: PR c++/47635 * decl.c (grokdeclarator): Don't set ctype to an ENUMERAL_TYPE. Added: trunk/gcc/testsuite/g++.dg/cpp0x/enum20.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug target/47333] [4.6 regression] g++.dg/lto/20091219 FAILs on Solaris 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333 --- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-06-20 14:42:12 UTC --- As a further datapoint, I've configured mainline with gas 2.21, but with HAVE_GAS_WEAKREF removed from auto-host.h. (Setting the autoconf configure variable to no didn't work somehow.) While the testcase works with HAVE_GAS_WEAKREF defined, it fails just as with Sun as with HAVE_GAS_WEAKREF undefined. I think it's pretty clear that this is not a target issue. Rainer
[Bug c++/49260] cpp0x/lambda/lambda-eh2.C fails execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2011-06-20 14:51:07 UTC ---
--- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-06
11:18:43 UTC ---
I'm seeing this when using Sun as on Solaris, but not with GNU as 2.21, even
when Sun ld is used in both cases.
I'm seeing it on SPARC/Solaris 8, 9 and 10 with GNU as 2.20.1 and Sun ld. So
the failure may be predicated on a feature available only in 2.21 or above.
I've digged somewhat further: with gas 2.20.1, one of the cfi configure
test fails
checking assembler for working cfi advance... no
thus HAVE_GAS_CFI_DIRECTIVE is 0 and gas and Sun as are treated the same.
If I look at the gas 2.20.1 output, I find 3 instances of
.long label / FDE initial location
_ZZ4mainENKUlvE_clEv- main::{lambda()#1}::operator()() const
.LFB32
_ZZ4mainENKUlvE0_clEv- main::{lambda()#2}::operator()() const
.LFB35
main
.LFB31
With gas 2.21 and .cfi_startproc instead, there are 5:
_ZZ4mainENKUlvE_clEv
.LFB32
_ZZ4mainENUlvE_4_FUNEv- main::{lambda()#1}::_FUN()
.LFB33
_ZZ4mainENKUlvE_cvPFvvEEv- main::{lambda()#1}::operator void (*)()()
const
.LFB34
_ZZ4mainENKUlvE0_clEv
.LFB35
main
.LFB31
The output of the FDE initial location happens in dwarf2out.c
(output_call_frame_info). If I step throught that function, I see that
the FDEs are only emitted if fde_needed_for_eh_p (fde). For the two
missing ones, I see that this function returns false due to this test:
/* If exceptions are enabled, we have collected nothrow info. */
if (flag_exceptions (fde-all_throwers_are_sibcalls || fde-nothrow))
return false;
Here, both fde-all_throwers_are_sibcalls and fde-nothrow are 1.
I cannot say if this is wrong or the tests in fde_needed_for_eh_p
needs to be augmented.
Manually returning true from the function caused the FDEs to be emitted
and the testcase to succeed, as expected.
Rainer
[Bug tree-optimization/49452] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.20 14:52:06 CC||eraman at google dot com Ever Confirmed|0 |1
[Bug c++/43321] [c++0x] ICE on valid auto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43321 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-06-20 14:54:13 UTC --- Fixed for 4.7.0.
[Bug middle-end/47725] [x32] error: unable to find a register to spill in class DIREG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47725 --- Comment #16 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-06-20 14:53:52 UTC --- Author: hjl Date: Mon Jun 20 14:53:48 2011 New Revision: 175218 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175218 Log: Check zero/sign extended hard registers. 2011-06-20 H.J. Lu hongjiu...@intel.com PR middle-end/47725 * combine.c (cant_combine_insn_p): Check zero/sign extended hard registers. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c
[Bug c++/37089] [C++0x] rvalue/lvalue reference collapsing not performed in error ouput thus printing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37089 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2011-06-20 14:54:30 UTC --- Fixed for 4.7.0.
[Bug c++/43831] [C++0x] gcc-4.5.0 does not fail invalid lambda captures (against n3092 5.1.2/8)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43831 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-06-20 14:55:05 UTC --- Fixed for 4.7.0.
[Bug c++/47635] [C++0x] ICE on invalid code in constructor_name_p, at cp/name-lookup.c:1809
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47635 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-06-20 14:55:36 UTC --- Fixed for 4.7.0.
[Bug rtl-optimization/49472] [4.7 regression] Compiler segfault on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49472
--- Comment #6 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-06-20
15:16:59 UTC ---
Gimple out of the middle end looks fine. From 142t.optimized:
;; Function nu_derivs (__massivenu_MOD_nu_derivs, funcdef_no=0, decl_uid=708,
cgraph_uid=0)
nu_derivs ()
{
real(kind=8) D.719;
real(kind=8) vdot;
integer(kind=4) iq;
real(kind=8) g1[4];
real(kind=8) aqdot;
real(kind=8) aq;
real(kind=8) adotoa;
integer(kind=8) D.736;
integer(kind=8) D.735;
real(kind=8) D.734;
real(kind=8) D.733;
real(kind=8) D.732;
real(kind=8) D.731;
real(kind=8) D.730;
real(kind=8) D.729;
real(kind=8) D.728;
real(kind=8) D.727;
bb 2:
# DEBUG iq = 2
bb 3:
# iq_1 = PHI 2(2), iq_19(3)
# DEBUG iq = iq_1
D.727_3 = (real(kind=8)) iq_1;
D.728_4 = D.727_3 - 1.5e+0;
D.729_5 = ((D.728_4));
aq_6 = 1.0e+0 / D.729_5;
# DEBUG aq = aq_6
# DEBUG aqdot = aq_6 * adotoa_7(D)
D.730_9 = __builtin_pow (aq_6, 2.0e+0);
D.731_10 = D.730_9 + 1.0e+0;
D.719_11 = ((D.731_10));
D.733_13 = __builtin_pow (D.719_11, -1.5e+0);
aqdot_8 = D.733_13 * adotoa_7(D);
D.732_12 = aqdot_8 * aq_6;
D.734_14 = D.732_12 * aq_6;
vdot_15 = -D.734_14;
# DEBUG vdot = vdot_15
D.735_16 = (integer(kind=8)) iq_1;
D.736_17 = D.735_16 + -1;
g1[D.736_17] = vdot_15;
iq_19 = iq_1 + 1;
# DEBUG iq = iq_19
if (iq_1 == 4)
goto bb 4;
else
goto bb 3;
bb 4:
dummy (g1);
return;
}
[Bug rtl-optimization/49472] [4.7 regression] Compiler segfault on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49472
--- Comment #7 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-06-20
15:18:55 UTC ---
Sorry, paste error. That was the wrong gimple dump. HERE is 142.optimized:
;; Function nu_derivs (__massivenu_MOD_nu_derivs, funcdef_no=0, decl_uid=708,
cgraph_uid=0)
nu_derivs ()
{
void * D.760;
unnamed-unsigned:64 ivtmp.14;
real(kind=8) powroot.4;
real(kind=8) powmult.2;
real(kind=8) D.719;
real(kind=8) vdot;
integer(kind=4) iq;
real(kind=8) g1[4];
real(kind=8) aqdot;
real(kind=8) aq;
real(kind=8) adotoa;
real(kind=8) D.734;
real(kind=8) D.732;
real(kind=8) D.731;
real(kind=8) D.729;
real(kind=8) D.728;
real(kind=8) D.727;
bb 2:
# DEBUG iq = 2
ivtmp.14_31 = (unnamed-unsigned:64) g1[0];
bb 3:
# iq_1 = PHI 2(2), iq_19(3)
# ivtmp.14_29 = PHI ivtmp.14_31(2), ivtmp.14_30(3)
# DEBUG iq = iq_1
D.727_3 = (real(kind=8)) iq_1;
D.728_4 = D.727_3 - 1.5e+0;
D.729_5 = ((D.728_4));
aq_6 = 1.0e+0 / D.729_5;
# DEBUG aq = aq_6
# DEBUG aqdot = aq_6 * adotoa_7(D)
powmult.2_25 = aq_6 * aq_6;
D.731_10 = powmult.2_25 + 1.0e+0;
D.719_11 = ((D.731_10));
powroot.4_26 = __builtin_sqrt (D.719_11);
powroot.4_27 = D.719_11 * powroot.4_26;
powroot.4_28 = 1.0e+0 / powroot.4_27;
aqdot_8 = powroot.4_28 * adotoa_7(D);
D.732_12 = aqdot_8 * aq_6;
D.734_14 = D.732_12 * aq_6;
vdot_15 = -D.734_14;
# DEBUG vdot = vdot_15
ivtmp.14_30 = ivtmp.14_29 + 8;
D.760_32 = (void *) ivtmp.14_30;
MEM[base: D.760_32, offset: 0B] = vdot_15;
iq_19 = iq_1 + 1;
# DEBUG iq = iq_19
if (iq_19 == 5)
goto bb 4;
else
goto bb 3;
bb 4:
dummy (g1);
return;
}
[Bug rtl-optimization/44194] struct returned by value generates useless stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194 --- Comment #33 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-20 15:27:06 UTC --- I think these two are totally independent of each other -- one should not be gated against each other. If Eawaran's approach is completely flawed, that is different story. With this change, we at least make incremental improvement. Not familiar with the rtl expander, but I guess the spilling was there probably for a deeper reason. If you have an insight, you can of course point it out. See comment #22. It's an incremental improvement, but maybe we can avoid wasting time and memory by creating RTXes and Trees that will be thrown away immediately after. I don't really see what we risk by trying.
[Bug bootstrap/49474] New: GCC 4.7-20110618 fails to bootstrap on stage 2: gcc/fortran/resolve.c:5360:1: internal compiler error: vector VEC(edge,base) index domain error, in find_implicit_sets at cpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49474 Summary: GCC 4.7-20110618 fails to bootstrap on stage 2: gcc/fortran/resolve.c:5360:1: internal compiler error: vector VEC(edge,base) index domain error, in find_implicit_sets at cprop.c:1346 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: dougmenc...@gmail.com Created attachment 24566 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24566 Preprocessed file gcc/fortran/resolve.i ICE on GCC code. /root/build-farm/_gcc_bootstrap/./prev-gcc/xgcc -B/root/build-farm/_gcc_bootstrap/./prev-gcc/ -B/usr/powerpc-gnu-linux-uclibc/bin/ -B/usr/powerpc-gnu-linux-uclibc/bin/ -B/usr/powerpc-gnu-linux-uclibc/lib/ -isystem /usr/powerpc-gnu-linux-uclibc/include -isystem /usr/powerpc-gnu-linux-uclibc/sys-include-c -DIN_GCC_FRONTEND -O3 -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -Ifortran -I../../gcc-v4.7-20110618.sourcedir/gcc -I../../gcc-v4.7-20110618.sourcedir/gcc/fortran -I../../gcc-v4.7-20110618.sourcedir/gcc/../include -I../../gcc-v4.7-20110618.sourcedir/gcc/../libcpp/include -I../../gcc-v4.7-20110618.sourcedir/gcc/../libdecnumber -I../../gcc-v4.7-20110618.sourcedir/gcc/../libdecnumber/dpd -I../libdecnumber ../../gcc-v4.7-20110618.sourcedir/gcc/fortran/resolve.c -o fortran/resolve.o ../../gcc-v4.7-20110618.sourcedir/gcc/fortran/resolve.c: In function 'update_arglist_pass': ../../gcc-v4.7-20110618.sourcedir/gcc/fortran/resolve.c:5360:1: internal compiler error: vector VEC(edge,base) index domain error, in find_implicit_sets at cprop.c:1346 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [fortran/resolve.o] Error 1 make[3]: Leaving directory `/root/build-farm/_gcc_bootstrap/gcc' ** Stage of native bootstrapping: stage 2. ** Host GCC -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-gnu-linux-uclibc/4.6.0/lto-wrapper Target: powerpc-gnu-linux-uclibc Configured with: ../gcc-v4.6-20110226.sourcedir/configure --prefix=/usr --sysconfdir=/etc --mandir=/usr/share/man --build=powerpc-gnu-linux-uclibc --host=powerpc-gnu-linux-uclibc --target=powerpc-gnu-linux-uclibc --enable-languages=c,c++,fortran,java --with-cpu=default32 --enable-threads=posix --with-system-zlib --with-libiconv-prefix=/usr --disable-nls --disable-werror --disable-multilib --disable-libssp --disable-__cxa_atexit --disable-checking --enable-shared --without-gjdoc --enable-libgcj --enable-libgcj-multifile --enable-interpreter --disable-libjava-multilib --disable-browser-plugin Thread model: posix gcc version 4.6.0 20110226 (experimental) (GCC) ** System type: powerpc-gnu-linux-uclibc (GNU/uClibc/Linux system on PowerPC). ** The options given when GCC was configured/built (from config.log): ../gcc-v4.7-20110618.sourcedir/configure --prefix=/usr --sysconfdir=/etc --mandir=/usr/share/man --build=powerpc-gnu-linux-uclibc --host=powerpc-gnu-linux-uclibc --target=powerpc-gnu-linux-uclibc --enable-languages=c,c++,fortran,java --with-cpu=default32 --enable-threads=posix --with-system-zlib --with-libiconv-prefix=/usr --disable-nls --disable-werror --disable-multilib --disable-libssp --disable-__cxa_atexit --disable-checking --enable-shared --without-gjdoc --enable-libgcj --enable-libgcj-multifile --enable-interpreter --disable-libjava-multilib --disable-browser-plugin ** Preprocessed file gcc/fortran/resolve.i: attached.
[Bug c++/49260] cpp0x/lambda/lambda-eh2.C fails execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260
--- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-20
15:55:38 UTC ---
The output of the FDE initial location happens in dwarf2out.c
(output_call_frame_info). If I step throught that function, I see that
the FDEs are only emitted if fde_needed_for_eh_p (fde). For the two
missing ones, I see that this function returns false due to this test:
/* If exceptions are enabled, we have collected nothrow info. */
if (flag_exceptions (fde-all_throwers_are_sibcalls || fde-nothrow))
return false;
Here, both fde-all_throwers_are_sibcalls and fde-nothrow are 1.
I cannot say if this is wrong or the tests in fde_needed_for_eh_p
needs to be augmented.
The former I presume: on the SPARC, in the assembly file, there is a call from
main::{lambda()#1}::_FUN() to main::{lambda()#1}::operator()() const and the
latter calls __cxa_throw. And this isn't a sibcall (we're at -O0).
Both flags are set to 1 initially in set_nothrow_function_flags but should be
properly computed later in the function.
[Bug c++/49205] [C++0x] Default constructor with pack expansion parameter not detected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49205 --- Comment #7 from Johannes Schaub schaub.johannes at googlemail dot com 2011-06-20 15:56:42 UTC --- (In reply to comment #6) (In reply to comment #1) While this behavior is erroneous, consensus at clang was that WG21 made an oversight in allowing this. Template constructors are banned from being copy or move constructors, and historically this prohibition was not necessary for default constructors since there was no special handling of them except when implicit. I disagree with this. As Johannes points out, it is possible to have a template default constructor in C++03, so changing this would be a significant change. We should just treat the variadic template as a default constructor. To be fair to Sean, I should note that my example relied on a C++0x feature. If we remove the template default argument: templatetypename T A(T = 0); This constructor cannot really be called with arguments anymore (there's no deduction from default arguments), which is the condition under which a constructor becomes a default constructor.
[Bug middle-end/47725] [x32] error: unable to find a register to spill in class DIREG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47725 --- Comment #17 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-20 16:01:53 UTC --- Check zero/sign extended hard registers. 2011-06-20 H.J. Lu hongjiu...@intel.com PR middle-end/47725 * combine.c (cant_combine_insn_p): Check zero/sign extended hard registers. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c Why are you installing this again? The patch isn't correct and I thought it was unnecessary in the end.
[Bug target/49391] [arm] sp not accepted as input for alu operation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49391 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||missed-optimization Last reconfirmed||2011.06.20 16:05:21 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.6.0, 4.7.0 Severity|minor |enhancement --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-06-20 16:05:21 UTC --- The bic / and instructions with constants should allow the SP register as a source in ARM state. cheers Ramana
[Bug rtl-optimization/49472] [4.7 regression] Compiler segfault on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49472
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org,
||jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-20
16:07:45 UTC ---
We seem to be oscillating on
exprA = (div:DF (reg:DF 98) (reg:DF 96))
exprB = (div:DF (const_double:DF 1.0e+0 [0x0.8p+1]) (reg:DF 90 [ powroot.4 ]))
op0:
(mult:DF exprA (neg:DF exprA))
op1:
exprB
and:
op0:
(mult:DF exprB (neg:DF exprA))
op1:
exprA
and:
op0:
(mult:DF exprA (neg:DF exprB))
op1:
exprA
(and then back to the first op0/op1 form) in:
1799 /* Canonicalize (x op c) op y as (x op y) op c. */
1800 if (swap_commutative_operands_p (XEXP (op0, 1), op1))
1801{
1802 tem = simplify_gen_binary (code, mode, XEXP (op0, 0), op1);
1803 return simplify_gen_binary (code, mode, tem, XEXP (op0, 1));
1804}
(each new occurrence of this is 7 frames deeper in the backtrace).
Not sure if this might be fixed by Alex' patch for PR48866 (if we generate
more debug temps, supposedly the expressions wouldn't be so large and we
wouldn't hit this.
Anyway, the issue here is that swap_commutative_operands_p thinks it is better
to have the negation in the second operand instead of second operand of the
first operand, but when we built it that way, MULT case in
simplify_binary_operation_1 attempts to move the NEG from the second operand to
the first one:
if (GET_CODE (op1) == NEG)
{
rtx temp = simplify_unary_operation (NEG, mode, op0, mode);
if (temp)
return simplify_gen_binary (MULT, mode, temp, XEXP (op1, 0));
}
then simplify_unary_operation_1 does:
689 /* (neg (mult A B)) becomes (mult (neg A) B).
690 This works even for floating-point values. */
691 if (GET_CODE (op) == MULT
692 !HONOR_SIGN_DEPENDENT_ROUNDING (mode))
693{
694 temp = simplify_gen_unary (NEG, mode, XEXP (op, 0), mode);
695 return simplify_gen_binary (MULT, mode, temp, XEXP (op, 1));
696}
and finally simplify_binary_operation_1 does:
1840 /* Make sure the constant is second. */
1841 if (GET_RTX_CLASS (code) == RTX_COMM_ARITH
1842 swap_commutative_operands_p (op0, op1))
1843{
1844 tem = op0, op0 = op1, op1 = tem;
1845}
[Bug rtl-optimization/44194] struct returned by value generates useless stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194 --- Comment #34 from davidxl xinliangli at gmail dot com 2011-06-20 16:25:04 UTC --- (In reply to comment #33) I think these two are totally independent of each other -- one should not be gated against each other. If Eawaran's approach is completely flawed, that is different story. With this change, we at least make incremental improvement. Not familiar with the rtl expander, but I guess the spilling was there probably for a deeper reason. If you have an insight, you can of course point it out. See comment #22. It's an incremental improvement, but maybe we can avoid wasting time and memory by creating RTXes and Trees that will be thrown away immediately after. I don't really see what we risk by trying. yes, of course -- since you have explicit suggestion, it can be tried. Easwaran might have looked into this more .. David
[Bug fortran/49475] New: [OOP] Add DWARF info for Fortran's OOP features (extension, member functions)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49475 Summary: [OOP] Add DWARF info for Fortran's OOP features (extension, member functions) Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org We should consider generating DWARF information for Fortran OOP features: type t integer :: a end type t type, EXTENDS(t) :: t2 integer :: b contains procedure :: member_proc = local_proc end type t2 type (t2) :: x In this example, x%a and x%t2%a access the component of the parent type. member_proc is a member function, which can be accessed as x%member_proc(); the actual function being called depends on the dynamic type and is determined via the vtable. DWARF4 does not really state what should be used in case of Fortran. At http://www.dwarfstd.org/doc/DWARF4.pdf one finds: - 5.5.3 Derived or Extended Structs, Classes and Interfaces - 5.5.7 Member Function Entries
[Bug other/42980] GCC parallel make install failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42980 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #14 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-06-20 16:34:28 UTC --- Seems fixed. If so, please close. If not, please summarize remaining issues.
[Bug rtl-optimization/44194] struct returned by value generates useless stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194 --- Comment #35 from Easwaran Raman eraman at google dot com 2011-06-20 16:51:18 UTC --- (In reply to comment #33) I think these two are totally independent of each other -- one should not be gated against each other. If Eawaran's approach is completely flawed, that is different story. With this change, we at least make incremental improvement. Not familiar with the rtl expander, but I guess the spilling was there probably for a deeper reason. If you have an insight, you can of course point it out. See comment #22. It's an incremental improvement, but maybe we can avoid wasting time and memory by creating RTXes and Trees that will be thrown away immediately after. I don't really see what we risk by trying. There is a comment in calls.c that says /* Handle calls that return values in multiple non-contiguous locations. The Irix 6 ABI has examples of this. */ I don't know if avoiding the copy breaks that ABI in any way so I didn't try that approach. In general, if the TARGET is non-NULL, I don't see how the copy can be avoided (but then, the tree EXPR corresponding to the target hopefully has the addressable flag set). In this particular case though TARGET is NULL. Is it just a matter of setting VALREG and let expand_assignment deal with it? Irrespective of how this case is handled, I think there may be other instances where a store generated during expansion may be redundant, but we don't know it at the point of generation. In such cases, is this approach of associating a tree expr with the temp rtx generated by the expanded reasonable?
[Bug middle-end/47725] [x32] error: unable to find a register to spill in class DIREG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47725 --- Comment #18 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-06-20 17:03:21 UTC --- Author: hjl Date: Mon Jun 20 17:03:16 2011 New Revision: 175222 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175222 Log: Don't check zero/sign extended hard registers. 2011-06-20 H.J. Lu hongjiu...@intel.com PR middle-end/47725 * combine.c (cant_combine_insn_p): Don't check zero/sign extended hard registers. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c
[Bug middle-end/49465] [4.7 Regression] Revision 175114 miscompiled 403.gcc in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49465 --- Comment #1 from Jeffrey A. Law law at redhat dot com 2011-06-20 17:05:56 UTC --- Something goofy happens when we compile loop.c in cpu2k6... Still investigating.
[Bug target/49423] [arm] internal compiler error: in push_minipool_fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2011-06-20 17:06:18 UTC --- It's caused by r164136: Author: jamborm Date: Thu Sep 9 23:38:23 2010 New Revision: 164136 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164136 Log: 2010-09-10 Martin Jambor mjam...@suse.cz PR tree-optimization/44972 * tree-sra.c: Include toplev.h. (build_ref_for_offset): Entirely reimplemented. ... That makes it probably related to PR49094, although in this PR's test case the one occurrence of attribute((aligned(N)) doesn't matter for the ICE.
[Bug tree-optimization/49443] gcc.dg/vect/vect-peel-3.c and vect-peel-4.c fail on IA64 after testsuite change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49443 --- Comment #3 from Steve Ellcey sje at cup dot hp.com 2011-06-20 17:12:41 UTC --- Yes, the patch in comment #2 fixes the failures on IA64.
[Bug c++/49476] New: Complex functions returning references (not following C++ standard)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49476 Summary: Complex functions returning references (not following C++ standard) Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: basil.al-daj...@intel.com In the C++ standard definition, section 26.2.7, std::real() and std::imag() are defined to be: template class T T real (const complex T x) template class T T imag (const complex T x) GCC version 4.5.2, these functions return references, unless -std=c++0x is specified. If a specialization of std::complex returns values for real() and imag(), an error during compilation will occur. When compiling the attached reproducer (complex.cpp), the following error occurs: $ g++ complex.cpp -o complex -Wall -Wextra In file included from complex.cpp:2:0: /usr/include/c++/4.5/complex: In function ‘_Tp std::real(std::complex_Tp) [with _Tp = f32]’: complex.cpp:42:22: instantiated from here /usr/include/c++/4.5/complex:544:23: error: invalid initialization of non-const reference of type ‘f32’ from an rvalue of type ‘value_type’ /usr/include/c++/4.5/complex: In function ‘_Tp std::imag(std::complex_Tp) [with _Tp = f32]’: complex.cpp:43:22: instantiated from here /usr/include/c++/4.5/complex:554:23: error: invalid initialization of non-const reference of type ‘f32’ from an rvalue of type ‘value_type’ Fix: A patch has been attached to this report (along with an example that would trigger the error) Additional System Information: $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --with-multiarch-defaults=i386-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/i386-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/i386-linux-gnu --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)
[Bug c++/49476] Complex functions returning references (not following C++ standard)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49476 --- Comment #1 from Basil basil.al-dajane at intel dot com 2011-06-20 17:22:12 UTC --- Created attachment 24567 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24567 Reproducer program
[Bug c++/49476] Complex functions returning references (not following C++ standard)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49476 --- Comment #2 from Basil basil.al-dajane at intel dot com 2011-06-20 17:22:36 UTC --- Created attachment 24568 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24568 Patch to fix issue
[Bug rtl-optimization/49477] New: Should have user/debugger-oriented fine-tuning of optimizations available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49477 Summary: Should have user/debugger-oriented fine-tuning of optimizations available Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org [N.B. This concerns tree-optimization issues too, albeit scheduling/delay slot scheduling and reload optimizations are probably the worst offenders.] As observed at the GCC gathering, we lack a way for users to specify what optimizations to suppress in terms of what the optimizations impact on debugging experience would be. When users want to debug a program, the often don't care what the transformations or algorithms are that make debugging hell, they just want them turned off, while leaving innocuous optimization active so that program size/runtime doesn't become too much of an issue. We have -O0 and -O1 traditionally associated with a general 'level' of debugging experience, but -O0 has been broken with the advent of always-on optimizations like tree constant folding by the over-generalization that people tune down optimization only for the sake of compiler speed, and -O1 has a rather fuzzy meaning on debugging at best. E.g. scheduling, delay slot scheduling, and code reordering done by reload to reduce register lifetimes cause fine-grained code reordering that makes stepping through the code very confusing, and also if you set a breakpoint and debug info for a variable is available, that does not mean that the state of the variable as any relation to the value it should have according to the source line you set the breakpoint on. Thus, it would be good if we had an option to turn off all fine grained code reordering, whatever phase or algorithm does it. And also an option to turn off all code reordering altogether. For cases where exactly hitting hardware watch points are important, an option to prevent any kind of store sinking or otherwise postponing writes to user variables and/or allocated memory would be useful. This might be differentiated on type of variable, e.g. global versus local. For local variables, strength reduction of a loop counter arguably prevents storing the loop index altogether, so should also be inhibited or watered down so that the stores occur. If the required debugging feature is that people want to be able to observe values of variables truthfully according to the source code, stores to memory location are not that important *provided that* we have debug info available to compute the value of each variable. And there should also be an option to just turn of all optimization that have any impact on program behaviour with regards to stepping, breakpoints, watchpoints, and observable/observed values, even if that makes the compilation take longer than our current optimizing -O0 because of code bloat. So we would have three levels of selecting optimizations: - -On / -Os, selecting optimizations depending on compilation effort / run time trade off and code size considerations. - Overriding this, options turning off or watering down optimizations that impact particular or any aspects of debugging. - Overriding this, options to turn specific optimizations on or off, for people who know what they are doing with regards to this micromanagement.
[Bug libstdc++/49476] Complex functions returning references (not following C++ standard)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49476 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-20 17:56:24 UTC --- Changed by http://gcc.gnu.org/ml/libstdc++/2004-01/msg00091.html c.f. http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1589.html http://gcc.gnu.org/ml/libstdc++/2008-05/msg00120.html
[Bug libstdc++/49476] Complex functions returning references (not following C++ standard)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49476 --- Comment #4 from Basil basil.al-dajane at intel dot com 2011-06-20 18:10:39 UTC --- The change doesn't fix the issue, as it is a solution for when -std=c++0x is specified. (In reply to comment #3) Changed by http://gcc.gnu.org/ml/libstdc++/2004-01/msg00091.html c.f. http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#387 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1589.html http://gcc.gnu.org/ml/libstdc++/2008-05/msg00120.html
[Bug libstdc++/49476] Complex functions returning references (not following C++ standard)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49476 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-20 18:21:01 UTC --- I don't think we should fix now, after 7 years, the return type of std::real and std::imag in C++03 mode, because this would cause serious ABI problems when objects build with pre- and post- complex header are linked together. Indeed, that's exactly why I changed the return-type only in C++0x mode, where we have leeway.
[Bug rtl-optimization/49429] [4.7 Regression] dse.c changes to fix PR44194 (r175063) cause execution failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49429
--- Comment #11 from Easwaran Raman eraman at google dot com 2011-06-20
18:40:46 UTC ---
(In reply to comment #10)
With regards to the question in comment #9, you would probably do better
asking
it on the gcc-patches mailing list then in the comment of this bug report
since
more people would see it on the mailing list.
Could you please try out this patch? I don't have the ia-64 host libraries and
have a half-broken cross compiler, but this seems to fix the issue in y.c.
Index: gcc/expr.c
===
--- gcc/expr.c(revision 175081)
+++ gcc/expr.c(working copy)
@@ -1181,8 +1181,19 @@ emit_block_move_hints (rtx x, rtx y, rtx size, enu
else if (may_use_call
ADDR_SPACE_GENERIC_P (MEM_ADDR_SPACE (x))
ADDR_SPACE_GENERIC_P (MEM_ADDR_SPACE (y)))
-retval = emit_block_move_via_libcall (x, y, size,
- method == BLOCK_OP_TAILCALL);
+{
+ /* Since x and y are passed to a libcall, mark the corresponding
+ tree EXPR as addressable. */
+ tree y_expr = MEM_EXPR (y);
+ tree x_expr = MEM_EXPR (x);
+ if (y_expr)
+mark_addressable (y_expr);
+ if (x_expr)
+mark_addressable (x_expr);
+ retval = emit_block_move_via_libcall (x, y, size,
+method == BLOCK_OP_TAILCALL);
+}
+
else
emit_block_move_via_loop (x, y, size, align);
[Bug ada/46350] s-taprop.adb:891:40: warning: redundant conversion, expression is of type Interrupt_ID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46350 --- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2011-06-20 18:57:16 UTC --- Still present in 4.6.1: /xxx/gnu/gcc/objdir/./gcc/xgcc -B/xxx/gnu/gcc/objdir/./gcc/ -B/opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/bin/ -B/opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/lib/ -isystem /opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/include -isystem /opt/gnu/gcc/gcc-4.6/hppa1.1-hp-hpux10.20/sys-include-c -g -O2 -W -Wall -gnatpg s-taprop.adb -o s-taprop.o s-taprop.adb:891:40: warning: redundant conversion, expression is of type Interrupt_ID make[5]: *** [s-taprop.o] Error 1 507 (hiauly1)dave ./xgcc -B./ -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: hppa1.1-hp-hpux10.20 Configured with: ../gcc/configure --with-gnu-as --with-as=/usr/local/bin/as --enable-shared --prefix=/opt/gnu/gcc/gcc-4.6 --with-gmp=/opt/gnu/gcc/gmp --enable-debug=no --disable-nls --enable-languages=c,c++,objc,fortran,ada,obj-c++ Thread model: single gcc version 4.6.1 20110619 (prerelease) [gcc-4_6-branch revision 175188] (GCC)
[Bug target/49422] [arm] unable to find a register to spill in class 'VFP_LO_REGS'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49422 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2011-06-20 18:58:00 UTC --- I've not been able to reproduce this ICE. How exactly was your gcc configured (arm-oe-linux-gnueabi-gcc -v)?
[Bug middle-end/49465] [4.7 Regression] Revision 175114 miscompiled 403.gcc in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49465 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |law at redhat dot com |gnu.org | --- Comment #2 from Jeffrey A. Law law at redhat dot com 2011-06-20 19:41:43 UTC --- We're mucking up a PHI argument in one particular case... I'm testing a fix.
[Bug c/49478] New: ice in expand_widen_pattern_expr with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49478 Summary: ice in expand_widen_pattern_expr with -O3 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 24569 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24569 C source code I just tried to compile the groona-1.2.2 package with the latest trunk snapshot 20110618 on an AMD x86_64 box. The compiler said io.c: In function 'grn_io_create_with_array': io.c:287:13: internal compiler error: in expand_widen_pattern_expr, at optabs.c:535 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O3 required.
[Bug fortran/49479] New: [4.6/4.7 Regression] reshape / optionals / zero sized arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49479 Summary: [4.6/4.7 Regression] reshape / optionals / zero sized arrays Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch Currently, CP2K seems miscompiled with the 4.6 and 4.7 branches. The following testcase is likely the issue: MODULE M1 IMPLICIT NONE CONTAINS SUBROUTINE S1(data) INTEGER, DIMENSION(:), INTENT(IN), OPTIONAL :: DATA IF (PRESENT(data)) WRITE(6,*) SIZE(data) END SUBROUTINE SUBROUTINE S2(N) INTEGER :: N INTEGER, ALLOCATABLE, DIMENSION(:, :):: blki ALLOCATE(blki(3,N)) blki=0 CALL S1(RESHAPE(blki,(/3*N/))) END SUBROUTINE END MODULE USE M1 CALL S2(0) END whereas gfortran 4.5 prints correctly 0, 4.6/4.7 print nothing.
[Bug fortran/49112] [4.6/4.7 Regression] [OOP] Missing type-bound procedure, duplicate save warnings and internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49112 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | --- Comment #11 from janus at gcc dot gnu.org 2011-06-20 19:55:54 UTC --- (In reply to comment #10) It can be fixed by this partial revert: === --- gcc/fortran/resolve.c(revision 174415) +++ gcc/fortran/resolve.c(working copy) @@ -964,9 +964,6 @@ resolve_structure_cons (gfc_expr *expr, int init) t = SUCCESS; - if (expr-ts.type == BT_DERIVED) -resolve_symbol (expr-ts.u.derived); - cons = gfc_constructor_first (expr-value.constructor); /* A constructor may have references if it is the result of substituting a parameter variable. In this case we just pull out the component we Unfortunately this patchlet seems to induce the following testsuite regressions: FAIL: gfortran.dg/func_assign_3.f90 -O0 (test for excess errors) FAIL: gfortran.dg/func_result_6.f90 -O0 (test for excess errors) FAIL: gfortran.dg/typebound_call_7.f03 -O (test for excess errors) FAIL: gfortran.dg/typebound_call_8.f03 -O (test for excess errors) The patch in comment #9, however, seems to be clean.
[Bug fortran/49479] [4.6/4.7 Regression] reshape / optionals / zero sized arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49479 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-06-20 20:04:47 UTC --- the difference (I think) seems to be in the present check that has become if (data != 0B (integer(kind=4)[0:] * restrict) data-data != 0B) instead of the original if (data != 0B)
[Bug fortran/49479] [4.6/4.7 Regression] reshape / optionals / zero sized arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49479 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.20 20:16:50 Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-20 20:16:50 UTC --- Revision 162456 is OK, 163718 is not.
[Bug rtl-optimization/49429] [4.7 Regression] dse.c changes to fix PR44194 (r175063) cause execution failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49429 --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-20 21:11:54 UTC --- The patch in comment #11 fixes the failures in comment #0. Thanks. Full testing will take ~20 hours.
[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918 --- Comment #58 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-20 21:12:42 UTC --- Author: burnus Date: Mon Jun 20 21:12:39 2011 New Revision: 175228 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175228 Log: 2011-06-20 Tobias Burnus bur...@net-b.de PR fortran/18918 * gfortran.h (gfc_check_vardef_context): Update prototype. (iso_fortran_env_symbol): Handle derived types. (symbol_attribute): Add lock_comp. * expr.c (gfc_check_vardef_context): Add LOCK_TYPE check. * interface.c (compare_parameter, gfc_procedure_use): Handle LOCK_TYPE. (compare_actual_formal): Update gfc_check_vardef_context call. * check.c (gfc_check_atomic_def, gfc_check_atomic_ref): Ditto. * intrinsic.c (check_arglist): Ditto. * io.c (resolve_tag, gfc_resolve_dt, gfc_resolve_inquire): * Ditto. * iso-fortran-env.def (ISOFORTRAN_LOCK_TYPE): Add. * intrinsic.texi (ISO_FORTRAN_ENV): Document LOCK_TYPE. * module.c (mio_symbol_attribute): Handle lock_comp. (create_derived_type): New function. (use_iso_fortran_env_module): Call it to handle LOCK_TYPE. * parse.c (parse_derived): Add constraint check for LOCK_TYPE. * resolve.c (resolve_symbol, resolve_lock_unlock): Add * constraint checks for LOCK_TYPE. (gfc_resolve_iterator, resolve_deallocate_expr, resolve_allocate_expr, resolve_code, resolve_transfer): Update gfc_check_vardef_context call. * trans-stmt.h (gfc_trans_lock_unlock): New prototype. * trans-stmt.c (gfc_trans_lock_unlock): New function. * trans.c (trans_code): Handle LOCK and UNLOCK. 2011-06-20 Tobias Burnus bur...@net-b.de PR fortran/18918 * gfortran.dg/coarray_lock_1.f90: Update dg-error. * gfortran.dg/coarray_lock_3.f90: New. * gfortran.dg/coarray/lock_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/coarray/lock_1.f90 trunk/gcc/testsuite/gfortran.dg/coarray_lock_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/io.c trunk/gcc/fortran/iso-fortran-env.def trunk/gcc/fortran/module.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-stmt.h trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/coarray_lock_1.f90
[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #59 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-20 21:17:52 UTC --- Close as FIXED. There is now a full parsing support for coarrays and with few exceptions (bugs), the single image support is complete. I think it thus makes sense to close this PR and track the remaining issues and the multi-image support elsewhere. See also http://gcc.gnu.org/wiki/Coarray
[Bug rtl-optimization/49429] [4.7 Regression] dse.c changes to fix PR44194 (r175063) cause execution failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49429 --- Comment #13 from Steve Ellcey sje at cup dot hp.com 2011-06-20 21:18:18 UTC --- Yes, it fixed the test case on ia64-hp-hpux11.23. I will put it in my nightly bootstrap and test setup and let you know the results of that tomorrow.
[Bug c++/49216] [C++0x][Regression] ICE on compiling new-expression with braced-init-list for arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49216 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.20 21:30:25 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug fortran/49479] [4.6/4.7 Regression] reshape / optionals / zero sized arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49479 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||burnus at gcc dot gnu.org Target Milestone|--- |4.6.2 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-20 21:39:28 UTC --- There seems to be a bug in the implementation of Fortran 2008's new feature: A null pointer or unallocated allocatable can be used to denote an absent nonallocatable nonpointer optional argument. That check has been added in Rev 163263 on 2010-08-15. However, I am not sure that the bug is in the new code - it could also be a RESHAPE bug (cf. PR 49324 for another reshape bug). I think gfortran's convention is - and also TR 29113 require that the addr_expr is not NULL if the variable is allocated - even if it is zero sized. However, I need to recheck and maybe also other library functions have this issue. Workaround: -std=f2003.
[Bug c++/49480] New: internal compiler error: output_operand: invalid expression as operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49480 Summary: internal compiler error: output_operand: invalid expression as operand Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: tom...@gmail.com When asked to compile the following C++ source, gcc gives the message internal compiler error: output_operand: invalid expression as operand The program in full (it's only one line long) is: char cc[300]; int c = *(int*)(int(cc[150]) ~15); Invoke gcc with no command line arguments, e.g. gcc sample.cc ( although I saw the same thing on x86_64 when compiling with -m32 ) g++ -v output: Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) uname -a output: Linux crux 2.6.32-32-generic #62-Ubuntu SMP Wed Apr 20 21:54:21 UTC 2011 i686 GNU/Linux
[Bug middle-end/49465] [4.7 Regression] Revision 175114 miscompiled 403.gcc in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49465 --- Comment #3 from Jeffrey A. Law law at redhat dot com 2011-06-20 22:51:17 UTC --- Fix looking good. Doing a cpu2k6 int test right now.
[Bug fortran/32986] Improve diagnostic message for COMMON with automatic object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32986
--- Comment #2 from afhoffie at ncsu dot edu 2011-06-20 23:02:09 UTC ---
Dear Sir or Madam,
I am trying to define an array index variable but also an allocatable array
in my fortran subroutine as a common object. This object is defined as a
global variable in C++ with externC{struct{}name_;}. However, the gfortran
compiler tells me: Error: variable in this context must be a constant.
Please see attached files.
Would appreciate any help. Thanks very much.
Best regards,
Andreas Hoffie
[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED CC||hjl.tools at gmail dot com Resolution|FIXED | --- Comment #60 from H.J. Lu hjl.tools at gmail dot com 2011-06-21 00:20:27 UTC --- On Linux/x86, I got FAIL: gfortran.dg/coarray_lock_3.f90 -O (test for errors, line 72)
