[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451 --- Comment #15 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-26 06:49:47 UTC --- Author: burnus Date: Tue Oct 26 06:49:43 2010 New Revision: 165936 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165936 Log: 2010-10-26 Tobias Burnus bur...@net-b.de PR fortran/45451 * trans-stmt.c (gfc_trans_allocate): Do a deep-copy for SOURCE=. PR fortran/43018 * trans-array.c (duplicate_allocatable): Use size of type and not the size of the pointer to the type. 2010-10-26 Tobias Burnus bur...@net-b.de PR fortran/45451 * gfortran.dg/class_allocate_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/class_allocate_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/43018] alloc_comp_scalar_1.f90: Valgrind Invalid read of size 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43018 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-26 06:49:47 UTC --- Author: burnus Date: Tue Oct 26 06:49:43 2010 New Revision: 165936 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165936 Log: 2010-10-26 Tobias Burnus bur...@net-b.de PR fortran/45451 * trans-stmt.c (gfc_trans_allocate): Do a deep-copy for SOURCE=. PR fortran/43018 * trans-array.c (duplicate_allocatable): Use size of type and not the size of the pointer to the type. 2010-10-26 Tobias Burnus bur...@net-b.de PR fortran/45451 * gfortran.dg/class_allocate_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/class_allocate_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/43018] alloc_comp_scalar_1.f90: Valgrind Invalid read of size 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43018 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-26 06:52:24 UTC --- FIXED on the trunk (4.6). As allocatable scalars have improved a lot in 4.6, thus I do not intent to backport to 4.5. But feel free to do so, if you think otherwise - the patch is trivial.
[Bug tree-optimization/46177] [4.5/4.6 Regression] ICE: in prop_phis, at tree-loop-distribution.c:327 with -fno-tree-copy-prop -ftree-loop-distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46177 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.26 07:06:29 CC||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-26 07:06:29 UTC --- It is caused by revision 145494: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00115.html
[Bug fortran/46174] [OOP] ALLOCATE with SOURCE: Deep copy missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46174 Salvatore Filippone sfilippone at uniroma2 dot it changed: What|Removed |Added CC||sfilippone at uniroma2 dot ||it --- Comment #1 from Salvatore Filippone sfilippone at uniroma2 dot it 2010-10-26 07:09:41 UTC --- (In reply to comment #0) The following is in a sense a follow up to PR 45451. Assuming that X and Y are both polymorphic (CLASS) and the following operation: ALLOCATE (x, SOURCE=y) or x = y ! Fortran 2008: (Re)alloc on assignment with polymorphic LHS What about MOLD= for polymorphic variables?
[Bug tree-optimization/46172] [4.2/4.3/4.4/4.5/4.6 Regression] ICE: in expand_widen_pattern_expr, at optabs.c:522 with -ftree-vectorize -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46172 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.26 07:11:43 Summary|ICE: in |[4.2/4.3/4.4/4.5/4.6 |expand_widen_pattern_expr, |Regression] ICE: in |at optabs.c:522 with|expand_widen_pattern_expr, |-ftree-vectorize|at optabs.c:522 with |-fno-tree-dce |-ftree-vectorize ||-fno-tree-dce Ever Confirmed|0 |1
[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Depends on||46174 --- Comment #16 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-26 07:35:44 UTC --- The test case of comment 4 is now fixed, namely: ALLOCATE (polymorphic, SOURCE=non-polymorphic) Unfixed is a polymorphic SOURCE= as this requires a deep copying of the effective type, cf. PR 46174. Consequently, the first test case (attachment 21592) will fail at allocate(a%a,source=b, stat=info) if b has any allocatable components. That's the case if b is of the effective type psb_d_csr_sparse_mat. Interestingly, wrapping the ALLOCATE in select type (b) type is (psb_d_csr_sparse_mat) allocate(a%a,source=b, stat=info) end select does not help :-( I do not know whether this SOURCE= problem is the only or only the main bug exposed by the first test case. * * * Unfixed is the diagnostic of passing a non-polymorphic actual to an *allocatable* polymorphic dummy. That accepts-invalid bug is PR 46161 and affects the second attachment (attachment 21613).
[Bug fortran/46174] [OOP] ALLOCATE with SOURCE: Deep copy missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46174 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-26 07:44:15 UTC --- (In reply to comment #1) What about MOLD= for polymorphic variables? MOLD= should work. Allocate with mold= allocates memory for the effective type of mold and initializes with the default initializer. By default, allocatable components are not allocated and thus there is no problem. (SOURCE= also works if (currently: and only if) all allocatable components are not allocated.) * * * Similarly affected: Deallocation when leaving the scope: The allocatable components of the effective type are not deallocated. Example: implicit none type t end type t type, extends(t) :: t2 integer, allocatable :: all end type t2 class(t), allocatable :: a if (allocated(a)) call foo() end If one looks at the dump, one sees that only allocatable components of the declared type (t, here: none) but not allocatable components of the effective type are freed. I think that's tightly coupled to FINALization subroutines, i.e. PR 37336.
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-26 07:45:53 UTC --- Related issue: When a polymorphic types has to be finallized, e.g. when it leaves the scope, the allocatable components of the effective type have to be freed - not only those of the declared type. Cf. PR 46174
[Bug target/46171] [4.6 Regression] ICE: in gen_rtx_SUBREG, at emit-rtl.c:774 with -fno-tree-dce -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46171 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-10-26 07:49:50 UTC --- It is caused by revision 165452: http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg00636.html
[Bug middle-end/46176] profile feedback causes 20% linux kernel binary growth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46176 --- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2010-10-26 08:01:01 UTC --- Thanks. Unrolling seems to be part of it, but not all. I rebuilt/retrained with -fno-unroll-loops Trained: textdata bss dec hex filename 127744891198572 1357680 15330741 e9edb5 vmlinux Untrained: 111364521200876 1357552 13694880 d0f7a0 ../obj-work2/vmlinux So it's only 13% difference now, but still a lot. function old new delta r600_kms_blit_copy 2640 16394 +13754 static.do_con_write- 10163 +10163 static.rv770_startup -9541 +9541 r600_blit_copy 10605 19626 +9021 e1000_setup_copper_link-8894 +8894 kmem_cache_create 1385 10227 +8842 des3_ede_encrypt12038208 +7005 des3_ede_decrypt12038208 +7005
`Installing GCC' documentation: ponctuation mistake in chapter `configure'
Dear developers, I read the chapter `Configure' from the `Installing GCC' documentation today (http://gcc.gnu.org/install/configure.html) and found the following passage: --with-sysroot --with-sysroot=dir Tells GCC to consider dir as the root of a tree that contains a (subset of) the root filesystem of the target operating system. I think `contains a (subset of) the root' should be written `contains (a subset of) the root'. Christophe
[Bug tree-optimization/46172] [4.2/4.3/4.4/4.5/4.6 Regression] ICE: in expand_widen_pattern_expr, at optabs.c:522 with -ftree-vectorize -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46172 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-26 08:21:32 UTC --- It is caused by revision 109954: http://gcc.gnu.org/ml/gcc-cvs/2006-01/msg00752.html
[Bug tree-optimization/46167] [4.5/4.6 Regression] ICE: SIGSEGV in flow_bb_inside_loop_p (cfgloop.c:776) with -O -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46167 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.26 08:25:36 CC||cfang at gcc dot gnu.org Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-26 08:25:36 UTC --- It is caused by revision 163207: http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00418.html
[Bug tree-optimization/46167] [4.5/4.6 Regression] ICE: SIGSEGV in flow_bb_inside_loop_p (cfgloop.c:776) with -O -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46167 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com Target Milestone|4.6.0 |4.5.2
[Bug tree-optimization/46168] [4.3/4.4/4.5/4.6 Regression] ICE: verify_ssa failed: definition in block 6 does not dominate use in block 5 with -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46168 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.26 08:36:39 Summary|ICE: verify_ssa failed: |[4.3/4.4/4.5/4.6 |definition in block 6 does |Regression] ICE: verify_ssa |not dominate use in block 5 |failed: definition in block |with -ftree-loop-linear |6 does not dominate use in ||block 5 with ||-ftree-loop-linear Ever Confirmed|0 |1
[Bug fortran/46010] I/O: Namelist-reading bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46010 --- Comment #10 from Marco van Hulten marco at hulten dot org 2010-10-26 09:13:28 UTC --- On Tue, 26 Oct 2010 01:37:08 + jvdelisle wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46010 --- Comment #9 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-10-26 01:37:04 UTC --- Created attachment 22156 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22156 Patch to fix this. I think my email service is out. I attach the patch here for review. It may show up on the list. I tried sending it three times. Thank you for the patch. I have no time right now to apply and check the patch, but maybe in the weekend. Cheers, Marco
[Bug c++/46162] Invalid SFINAE with static member function/variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46162 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2010-10-26 09:13:45 UTC --- Looks related to PR46170.
[Bug c++/46170] [4.4/4.5/4.6 Regression] g++ wrongly rejects pointer-to-member in template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46170 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com Summary|g++ wrongly rejects |[4.4/4.5/4.6 Regression] |pointer-to-member in|g++ wrongly rejects |template arguments |pointer-to-member in ||template arguments --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2010-10-26 09:17:49 UTC --- Looks like a regression to me.
[Bug c++/46170] [4.4/4.5/4.6 Regression] g++ wrongly rejects pointer-to-member in template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46170 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.26 09:18:07 Ever Confirmed|0 |1
[Bug c/46180] New: CSE across calls to fesetround()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46180
Summary: CSE across calls to fesetround()
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zimmerma+...@loria.fr
with this program:
#include stdio.h
#include fenv.h
int main()
{
double x = 3.0;
fesetround (FE_DOWNWARD);
printf (1/3 arrondi vers -Inf: %.17f\n, 1.0 / x);
fesetround (FE_UPWARD);
printf (1/3 arrondi vers +Inf: %.17f\n, 1.0 / x);
}
I get with gcc 4.4.4:
tarte% gcc -O1 ex.c -lm
tarte% ./a.out
1/3 arrondi vers -Inf: 0.1
1/3 arrondi vers +Inf: 0.1
while -O0 gives the expected results:
tarte% ./a.out
1/3 arrondi vers -Inf: 0.1
1/3 arrondi vers +Inf: 0.7
Kaveh Ghazi believes this is due to incorrect CSE across calls to fesetround().
Also the following program:
#include stdio.h
#include math.h
#include fenv.h
int main()
{
double x = 3.0;
fesetround (FE_DOWNWARD);
printf (sin(3) arrondi vers -Inf: %.17f\n, sin (x));
fesetround (FE_UPWARD);
printf (sin(3) arrondi vers +Inf: %.17f\n, sin (x));
fesetround (FE_TONEAREST);
printf (sin(3) arrondi au plus proche : %.17f\n, sin (x));
fesetround (FE_TOWARDZERO);
printf (sin(3) arrondi vers 0 : %.17f\n, sin (x));
}
gives with -O0:
tarte% gcc -O0 ex2.c -lm; ./a.out
sin(3) arrondi vers -Inf: 2.78837698122124511
sin(3) arrondi vers +Inf: 0.14112000805986724
sin(3) arrondi au plus proche : 0.14112000805986721
sin(3) arrondi vers 0 : 2.78837698122124511
And with -O1 or -O2:
tarte% gcc -O1 ex2.c -lm ; ./a.out
sin(3) arrondi vers -Inf: 0.14112000805986721
sin(3) arrondi vers +Inf: 0.14112000805986721
sin(3) arrondi au plus proche : 0.14112000805986721
sin(3) arrondi vers 0 : 0.14112000805986721
Kaveh Ghazi found that when compiling the code with -fdump-tree-all
-frounding-math -lm -O1 the
body of main() is transformed into the code below:
main ()
{
double D.4342;
bb 2:
fesetround (1024);
D.4342_2 = sin (3.0e+0);
printf (sin(3) arrondi vers -Inf: %.17f\n[0], D.4342_2);
fesetround (2048);
printf (sin(3) arrondi vers +Inf: %.17f\n[0], D.4342_2);
fesetround (0);
printf (sin(3) arrondi au plus proche : %.17f\n[0], D.4342_2);
fesetround (3072);
printf (sin(3) arrondi vers 0 : %.17f\n[0], D.4342_2);
return;
}
which clearly shows that sin(3.0) is computed only once, although the rounding
mode changed.
Paul Zimmermann
PS: a separate issue is that the rounding of sin(3) towards 0 and -Inf are
completely out of the allowed range [-1,1] for -O0...
[Bug c/46180] CSE across calls to fesetround()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46180 Vincent Lefèvre vincent at vinc17 dot org changed: What|Removed |Added CC||vincent at vinc17 dot org --- Comment #1 from Vincent Lefèvre vincent at vinc17 dot org 2010-10-26 10:05:33 UTC --- Dup of bug 34678.
[Bug c/46181] New: Feature request: free-like attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46181
Summary: Feature request: free-like attribute
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m.j.tha...@googlemail.com
It would be nice for purposes of static error checking to be able to mark
functions as destructors for some resource. Specifically, that a if a value is
passed from a variable to argument n of the function then it is no longer valid
after the call to the function. Optionally with an invalid value that may be
assigned to the variable afterwards.
E.g.
int close(int fd) __attribute__(( free(1, -1) )); /* Says that the value
passed to the first argument is invalid hereafter, and that the variable it
came from can be marked invalid by setting it to -1 */
So that the compiler can see that the following is bad:
int fd = open(filename, O_CREAT);
...
if (close(fd) 0) { ... }
do_something_with(fd);
but the following might be alright:
int fd = open(filename, O_CREAT);
...
if (close(fd) 0) { ... }
fd = -1;
do_something_with(fd);
It might also make sense to be able to tag a typedef as a resource type with
information about a free-like function and an invalid value:
typedef int myfile __attribute(( resource(close, -1) ));
[Bug libstdc++/45999] runtime error in std::vector python pretty printer.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45999 --- Comment #4 from Pawel Sikora pluto at agmk dot net 2010-10-26 10:27:02 UTC --- (In reply to comment #3) I've backported the fix: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165658 Thanks for trying the printers and submitting bug reports, Pawel btw. just FYI, this change causes syntax-error on python-2.4 based distros. Traceback (most recent call last): File string, line 3, in ? File /local/devel/toolchain45/x86_64-gnu-linux.mt_alloc/share/gcc-4.5.2/python/libstdcxx/v6/printers.py, line 180 obit = 1 if elt (1 self.so) else 0 ^ SyntaxError: invalid syntax /ahome/pawels/.gdbinit:14: Error in sourced command file: Error while executing Python code.
[Bug middle-end/46176] profile feedback causes 20% linux kernel binary growth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46176 --- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org 2010-10-26 10:28:34 UTC --- Interesting tidbit: the file containing r600_kms_blit_copy -- which grew most -- didn't get any profile feedback during training, there was no data file. I generated lists and cgraph ipa dumps for the feedback, non feedback compilations: dumps: http://halobates.de/tmp/20percent/r600_blit_kms.c.000i.cgraph-plain http://halobates.de/tmp/20percent/r600_blit_kms.c.000i.cgraph-feedback listings: http://halobates.de/tmp/20percent/r600_blit_kms.lst-plain http://halobates.de/tmp/20percent/r600_blit_kms.lst-feedback
[Bug c/46180] CSE across calls to fesetround()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46180 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||paolo.carlini at oracle dot ||com Resolution||DUPLICATE --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2010-10-26 10:32:24 UTC --- Ok. *** This bug has been marked as a duplicate of bug 34678 ***
[Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||zimmerma+gcc at loria dot ||fr --- Comment #17 from Paolo Carlini paolo.carlini at oracle dot com 2010-10-26 10:32:24 UTC --- *** Bug 46180 has been marked as a duplicate of this bug. ***
[Bug libstdc++/45999] runtime error in std::vector python pretty printer.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45999 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-26 10:48:23 UTC --- that must be present on trunk too, right? if GDB can be built with python 2.4 then our pretty printers should work with it too, I can change that printer to avoid using the conditional expression
[Bug tree-optimization/46168] [4.3/4.4/4.5/4.6 Regression] ICE: verify_ssa failed: definition in block 6 does not dominate use in block 5 with -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46168 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||spop at gcc dot gnu.org --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-10-26 11:11:35 UTC --- It is caused by revision 129494: http://gcc.gnu.org/ml/gcc-cvs/2007-10/msg00599.html
[Bug libstdc++/45999] runtime error in std::vector python pretty printer.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45999 --- Comment #6 from Pawel Sikora pluto at agmk dot net 2010-10-26 11:29:58 UTC --- (In reply to comment #5) that must be present on trunk too, right? this is a backport from, so probably trunk is affected too. if GDB can be built with python 2.4 then our pretty printers should work with it too, I can change that printer to avoid using the conditional expression gdb-7.2 builds/works fine on centos-5.x (RHEL5 equivalent) python-2.4 enviroment.
[Bug libfortran/46182] New: Run time check for invalid use of unallocated allocatable variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46182 Summary: Run time check for invalid use of unallocated allocatable variables Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr While the following code type b integer, allocatable :: i(:) end type b type(b), allocatable :: a(:) !allocate(a(10)) print *, allocated(a)!, allocated(a(1)%i) !deallocate(a) end seems to be a valid f2003 code and gives 'F' at run time, replacing print *, allocated(a)!, allocated(a(1)%i) with print *, allocated(a), allocated(a(1)%i) gives a Segmentation fault at run time (it gives 'T F' if the allocate/deallocate lines are uncommented). When asked on IRC about this kind of inquiry of a component of an unallocated derived type, Tobias Burnus answered immediately that such a use is invalid, pointing to 2.4.9 Allocatable variables ... 2 An unallocated allocatable variable shall not be referenced or defi ned. ... Then he made the comment that (obviously) this restriction does not apply for 13.7.11 ALLOCATED (ARRAY) or ALLOCATED (SCALAR) 1 Description. Query allocation status. 2 Class. Inquiry function. 3 Arguments. ARRAY shall be an allocatable array. SCALAR shall be an allocatable scalar. 4 Result Characteristics. Default logical scalar. 5 Result Value. The result has the value true if the argument (ARRAY or SCALAR) is allocated and has the value false if the argument is unallocated. but that 'a(1)%i' is not an array but an invalid expression per 2.4.9 that cannot be a valid argument of allocated. Note that my original problem came from scalar allocatable and that the above was less obvious for 'a%i'. It would be nice to have a run time check for such invalid use of unallocated allocatable variables (such as -fcheck=use_unalloc).
[Bug libstdc++/44436] [C++0x] Implement insert() and emplace* in associative and unordered containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44436 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2010-10-26 12:17:06 UTC --- First, I'm going to add the new insert overloads to the unordered containers.
[Bug libstdc++/44436] [C++0x] Implement insert() and emplace* in associative and unordered containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44436 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-26 12:27:33 UTC --- taking 'iterator' params for consistency, or 'const_iterator' because we don't have to maintain compatibility?
[Bug libstdc++/44436] [C++0x] Implement insert() and emplace* in associative and unordered containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44436 --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2010-10-26 12:31:28 UTC --- I would say const_iterator, consistently with the existing insert and erase overloads...
[Bug libstdc++/44436] [C++0x] Implement insert() and emplace* in associative and unordered containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44436 --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-26 12:39:59 UTC --- doh, of course, we already use const_iterator in the unordered containers. sorry!
[Bug fortran/46161] [OOP] Invalid: Passing non-polymorphic to allocatable polymorphic dummy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46161
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2010.10.26 13:04:05
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from janus at gcc dot gnu.org 2010-10-26 13:04:05 UTC ---
Preliminary patch:
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 165936)
+++ gcc/fortran/interface.c (working copy)
@@ -1519,6 +1520,18 @@ compare_parameter (gfc_symbol *formal, gfc_expr *a
gfc_typename (formal-ts));
return 0;
}
+
+ /* F2003, 12.5.2.5. */
+ if (formal-ts.type == BT_CLASS
+ (CLASS_DATA (formal)-attr.pointer
+ || CLASS_DATA (formal)-attr.allocatable)
+ actual-ts.type != BT_CLASS)
+{
+ if (where)
+ gfc_error (Actual argument to '%s' at %L must be polymorphic,
+ formal-name, actual-where);
+ return 0;
+}
if (formal-attr.codimension)
{
[Bug c++/46170] [4.4/4.5/4.6 Regression] g++ wrongly rejects pointer-to-member in template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46170 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||dseketel at redhat dot com --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2010-10-26 13:10:13 UTC --- It is caused by revision 153822: http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00038.html
Re: [Bug libfortran/46182] New: Run time check for invalid use of unallocated allocatable variables
It would be nice to have a run time check for such invalid use of unallocated allocatable variables (such as -fcheck=use_unalloc). If you use an unallocated variable you get a segmentation fault. Isn't this a sufficient runtime check ?
[Bug rtl-optimization/45454] [4.6 Regression] ICE: in verify_target_availability, at sel-sched.c:1614
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45454 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-26 13:20:29 UTC --- P2, because var-tracking is disabled by default for sel-sched, you need to explicitly force it.
[Bug target/45250] [4.6 Regression] FAIL: tr1/5_numerical_facilities/special_functions/01_assoc_laguerre/check_nan.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45250 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Status|WAITING |ASSIGNED CC||jakub at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-26 13:25:19 UTC --- I'll retest my patch and submit. P2 as PA is now fixed.
[Bug fortran/46174] [OOP] ALLOCATE with SOURCE: Deep copy missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46174
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||domob at gcc dot gnu.org
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2010-10-26
13:27:11 UTC ---
Possible implementation scheme: vtab$t contains besides the normal type-bound
procedures and init/size/hash also an two function points: $copy and $free,
which are of the kind:
void $free (struct *DT) {
... free derived types
if (DT-$vtab-$extends DT-$vtab-$extends-$free)
DT-$vtab-$extends-$free (DT)
}
That is, each effective type cleans up its own allocatable components and moves
on to the parent. If the parent does not have an allocatable component itself,
the $free pointer directly points to an ancestor which has -- or is NULL if no
such ancestor exists. The $copy version works alike.
[Bug c++/45894] [4.5/4.6 Regression] [C++0x] ICE: segmentation fault with -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45894 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/46183] New: [4.6 Regression] ICE: in calc_dfs_tree, at dominance.c:396 with -O -fno-dse -fgcse -ftree-pre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46183 Summary: [4.6 Regression] ICE: in calc_dfs_tree, at dominance.c:396 with -O -fno-dse -fgcse -ftree-pre Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 22159 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22159 reduced testcase Compiler output: $ gcc -O -fno-dse -fgcse -ftree-pre pr46183.c pr46183.c: In function 'foo': pr46183.c:16:1: internal compiler error: in calc_dfs_tree, at dominance.c:396 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r165915 - crash r161659 - crash r159696 - OK 4.5 r165781 - OK
[Bug tree-optimization/46167] [4.5/4.6 Regression] ICE: SIGSEGV in flow_bb_inside_loop_p (cfgloop.c:776) with -O -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46167 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org
[Bug middle-end/45687] [4.6 Regression] possible wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45687 --- Comment #4 from ian at gcc dot gnu.org ian at gcc dot gnu.org 2010-10-26 13:39:41 UTC --- Author: ian Date: Tue Oct 26 13:39:37 2010 New Revision: 165964 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165964 Log: gcc/: PR middle-end/45687 * ipa-prop.c (ipa_modify_call_arguments): Correct type of MEM_REF offset. gcc/testsuite: * gcc.c-torture/execute/20101025-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/20101025-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c trunk/gcc/testsuite/ChangeLog
[Bug target/46080] [4.4/4.5/4.6 Regression] incorrect precision of sqrtf builtin for x87 arithmetic (-mfpmath=387)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-26 13:41:10 UTC --- Well, the setting of errno by calling another function has similar effects like calling any other function in between, if you do float a = sqrtf (x); foo (); float b = sqrtf (x); bar (); float c = sqrtf (x); printf (%f %f %f\n, a, b, c); then there is similar problem - every call in between on i?86/x86_64 will clobber the i387 register stack in the ABI, so the values need to be flushed into memory and thus with the fast extended precision mode rounded to floating point precision, but the c value is probably kept in reg-stack and saved as a double instead of float, because of varargs in printf. Thus it can have different value.
[Bug middle-end/45687] [4.6 Regression] possible wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45687 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||ian at airs dot com Resolution||FIXED --- Comment #5 from Ian Lance Taylor ian at airs dot com 2010-10-26 13:43:31 UTC --- Fixed. Thanks for finding it.
[Bug tree-optimization/46183] [4.6 Regression] ICE: in calc_dfs_tree, at dominance.c:396 with -O -fno-dse -fgcse -ftree-pre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46183 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug target/44948] -msse/-mavx change ABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948 --- Comment #22 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2010-10-26 13:56:46 UTC --- Author: hjl Date: Tue Oct 26 13:56:42 2010 New Revision: 165965 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165965 Log: Properly align parameters on stack for x86. gcc/ 2010-10-26 H.J. Lu hongjiu...@intel.com PR target/44948 * config/i386/i386.c (ix86_old_function_arg_boundary): New. (ix86_function_arg_boundary): Always align parameters on stack in 64bit and align parameters with alignment = 16byte on stack in 32bit. Warn alignment change. gcc/testsuite/ 2010-10-26 H.J. Lu hongjiu...@intel.com PR target/44948 * g++.dg/abi/param2.C: Add -Wno-psabi for ilp32 x86. * g++.dg/vect/pr33860a.cc: Likewise. * gcc.c-torture/compile/20070522-1.c: Likewise. * gcc.dg/compat/struct-align-1_x.c: Likewise. * gcc.dg/compat/struct-align-1_y.c: Likewise. * gcc.dg/compat/struct-align-2_x.c: Likewise. * gcc.dg/compat/struct-align-2_y.c: Likewise. * gcc.dg/pr44136.c: Likewise. * gcc.c-torture/compile/pr33617.c: Add -Wno-psabi for x86. * gcc.dg/compat/vector-1_x.c: Likewise. * gcc.dg/compat/vector-1_y.c: Likewise. * gcc.dg/compat/vector-2_x.c: Likewise. * gcc.dg/compat/vector-2_y.c: Likewise. * gcc.dg/pr43300.c: Likewise. * gcc.dg/compat/vector-1a_x.c: Add -Wno-psabi. * gcc.dg/compat/vector-1a_y.c: Likewise. * gcc.dg/compat/vector-1b_x.c: Likewise. * gcc.dg/compat/vector-1b_y.c: Likewise. * gcc.dg/compat/vector-2a_x.c: Likewise. * gcc.dg/compat/vector-2a_y.c: Likewise. * gcc.dg/compat/vector-2b_x.c: Likewise. * gcc.dg/compat/vector-2b_y.c: Likewise. * gcc.target/i386/pr39162.c: Likewise. * gcc.target/i386/pr40906-2.c: Likewise. * gcc.target/i386/sse-5.c: Likewise. * gcc.dg/pr35442.c: Prune ABI change warnings. * gcc.c-torture/execute/pr38151.x: New. * gcc.target/i386/pr44948-1a.c: Likewise. * gcc.target/i386/pr44948-1b.c: Likewise. * gcc.target/i386/pr44948-2a.c: Likewise. * gcc.target/i386/pr44948-2b.c: Likewise. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr38151.x trunk/gcc/testsuite/gcc.target/i386/pr44948-1a.c trunk/gcc/testsuite/gcc.target/i386/pr44948-1b.c trunk/gcc/testsuite/gcc.target/i386/pr44948-2a.c trunk/gcc/testsuite/gcc.target/i386/pr44948-2b.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/abi/param2.C trunk/gcc/testsuite/g++.dg/vect/pr33860a.cc trunk/gcc/testsuite/gcc.c-torture/compile/20070522-1.c trunk/gcc/testsuite/gcc.c-torture/compile/pr33617.c trunk/gcc/testsuite/gcc.dg/compat/struct-align-1_x.c trunk/gcc/testsuite/gcc.dg/compat/struct-align-1_y.c trunk/gcc/testsuite/gcc.dg/compat/struct-align-2_x.c trunk/gcc/testsuite/gcc.dg/compat/struct-align-2_y.c trunk/gcc/testsuite/gcc.dg/compat/vector-1_x.c trunk/gcc/testsuite/gcc.dg/compat/vector-1_y.c trunk/gcc/testsuite/gcc.dg/compat/vector-1a_x.c trunk/gcc/testsuite/gcc.dg/compat/vector-1a_y.c trunk/gcc/testsuite/gcc.dg/compat/vector-1b_x.c trunk/gcc/testsuite/gcc.dg/compat/vector-1b_y.c trunk/gcc/testsuite/gcc.dg/compat/vector-2_x.c trunk/gcc/testsuite/gcc.dg/compat/vector-2_y.c trunk/gcc/testsuite/gcc.dg/compat/vector-2a_x.c trunk/gcc/testsuite/gcc.dg/compat/vector-2a_y.c trunk/gcc/testsuite/gcc.dg/compat/vector-2b_x.c trunk/gcc/testsuite/gcc.dg/compat/vector-2b_y.c trunk/gcc/testsuite/gcc.dg/pr35442.c trunk/gcc/testsuite/gcc.dg/pr43300.c trunk/gcc/testsuite/gcc.dg/pr44136.c trunk/gcc/testsuite/gcc.target/i386/pr39162.c trunk/gcc/testsuite/gcc.target/i386/pr40906-2.c trunk/gcc/testsuite/gcc.target/i386/sse-5.c
[Bug tree-optimization/46177] [4.5/4.6 Regression] ICE: in prop_phis, at tree-loop-distribution.c:327 with -fno-tree-copy-prop -ftree-loop-distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46177 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.5.2 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-26 13:57:20 UTC --- Mine.
[Bug tree-optimization/46184] New: [4.6 Regression] ICE: SIGSEGV in vectorizable_reduction (tree-vect-loop.c:4067) with -O -ftree-vectorize -fno-tree-copy-prop -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46184 Summary: [4.6 Regression] ICE: SIGSEGV in vectorizable_reduction (tree-vect-loop.c:4067) with -O -ftree-vectorize -fno-tree-copy-prop -fno-tree-dce Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 22160 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22160 reduced testcase (from gcc.dg/vect/vect-cond-4.c) valgrind output: $ gcc -O -ftree-vectorize -fno-tree-copy-prop -fno-tree-dce pr46184.c ==10721== Invalid read of size 2 ==10721==at 0x9DC5C2: vectorizable_reduction (tree-vect-loop.c:4067) ==10721==by 0x9D3D1A: vect_analyze_stmt (tree-vect-stmts.c:4661) ==10721==by 0x9DF616: vect_analyze_loop (tree-vect-loop.c:1248) ==10721==by 0x9EC288: vectorize_loops (tree-vectorizer.c:219) ==10721==by 0x797A5E: execute_one_pass (passes.c:1560) ==10721==by 0x797CF4: execute_pass_list (passes.c:1615) ==10721==by 0x797D06: execute_pass_list (passes.c:1616) ==10721==by 0x797D06: execute_pass_list (passes.c:1616) ==10721==by 0x8E4B65: tree_rest_of_compilation (tree-optimize.c:422) ==10721==by 0xAAF281: cgraph_expand_function (cgraphunit.c:1494) ==10721==by 0xAB1849: cgraph_optimize (cgraphunit.c:1553) ==10721==by 0xAB1DA9: cgraph_finalize_compilation_unit (cgraphunit.c:1016) ==10721== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==10721== pr46184.c: In function 'foo': pr46184.c:4:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r165915 - crash r159696 - crash r158095 - OK 4.5 r165781 - OK
[Bug target/44948] -msse/-mavx change ABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #23 from H.J. Lu hjl.tools at gmail dot com 2010-10-26 13:58:57 UTC --- Fixed.
[Bug tree-optimization/46172] [4.3/4.4/4.5/4.6 Regression] ICE: in expand_widen_pattern_expr, at optabs.c:522 with -ftree-vectorize -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46172 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.3.6 Summary|[4.2/4.3/4.4/4.5/4.6|[4.3/4.4/4.5/4.6 |Regression] ICE: in |Regression] ICE: in |expand_widen_pattern_expr, |expand_widen_pattern_expr, |at optabs.c:522 with|at optabs.c:522 with |-ftree-vectorize|-ftree-vectorize |-fno-tree-dce |-fno-tree-dce
[Bug tree-optimization/46168] [4.3/4.4/4.5/4.6 Regression] ICE: verify_ssa failed: definition in block 6 does not dominate use in block 5 with -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46168 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.3.6
[Bug tree-optimization/46165] [4.3/4.4/4.5/4.6 Regression] ICE: verify_flow_info failed when casting-out attribute noreturn with -fno-tree-ccp -fno-tree-copy-prop -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46165 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.3.6
[Bug libfortran/46182] Run time check for invalid use of unallocated allocatable variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46182 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-10-26 14:06:55 UTC --- Forwarded from http://gcc.gnu.org/ml/gcc-bugs/2010-10/msg02167.html It would be nice to have a run time check for such invalid use of unallocated allocatable variables (such as -fcheck=use_unalloc). If you use an unallocated variable you get a segmentation fault. Isn't this a sufficient runtime check ? Well! You can say the same thing for -fcheck=bounds if writing outside array bounds gives you a segmentation fault! Nevertheless nobody will argue that this check is useless: it can save you hours of debugging to locate the line(s) in which you do it. Segmentation faults tell you that there is something wrong, but not why and/or where (not counting gfortran bugs). It took me some time to understand it for a less than 20 line code in which I had the bad idea of using a copy and paste from a valid line to an invalid one (this can happen to anybody with kloc!-)
[Bug c++/46160] [4.5/4.6 Regression] ICE with volatile structure and enum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46160 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.5.2
[Bug c/46157] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46157 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.10.26 14:10:42 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-26 14:10:42 UTC --- Please attach preprocessed source.
[Bug target/46153] [4.5/4.6 Regression] ICE: in extract_insn, at recog.c:2110 (unrecognizable insn) with -ffloat-store and __builtin_ia32_movlhps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46153 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.5.2
[Bug tree-optimization/46149] [4.6 Regression] 26_numerics/valarray/27867.cc FAILs with -O2 -fno-tree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46149 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.0 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-26 14:14:20 UTC --- Mine.
[Bug tree-optimization/46184] [4.6 Regression] ICE: SIGSEGV in vectorizable_reduction (tree-vect-loop.c:4067) with -O -ftree-vectorize -fno-tree-copy-prop -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46184 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug middle-end/46185] New: [4.6 Regression] gcc.dg/graphite/interchange-4.c FAILs with -fno-ipa-cp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46185 Summary: [4.6 Regression] gcc.dg/graphite/interchange-4.c FAILs with -fno-ipa-cp Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Output (with #define DEBUG 1): $ gcc -O2 -floop-interchange -ffast-math interchange-4.c ./a.out res = 3565793 $ gcc -O2 -floop-interchange -ffast-math interchange-4.c -fno-ipa-cp ./a.out res = 1343 Aborted $ gcc -O1 -floop-interchange -ffast-math interchange-4.c ./a.out res = 1343 Aborted The same effect can be achieved by adding attribute noclone to foo(). Tested revisions: r165915 - fail r163636 - fail r161659 - OK
[Bug c/46186] New: Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 Summary: Clang creates code running 1600 times faster than gcc's Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@jak-linux.org Created attachment 22161 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22161 C file The attached code compiles into an executable that takes 1.6 seconds to run, when compiled with clang, it takes 0.001 seconds (both with -O2 as the only compiler option).
[Bug libfortran/46182] Run time check for invalid use of unallocated allocatable variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46182 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.26 14:29:15 CC||mikael at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Mikael Morin mikael at gcc dot gnu.org 2010-10-26 14:29:15 UTC --- (In reply to comment #1) Well! You can say the same thing for -fcheck=bounds if writing outside array bounds gives you a segmentation fault! Nevertheless nobody will argue that this check is useless: it can save you hours of debugging to locate the line(s) in which you do it. Well, my point was that an out of bound access doesn't necessarily faults whereas a NULL pointer access always does. Anyway, it can't do any harm. Confirmed.
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #1 from Julian Andres Klode j...@jak-linux.org 2010-10-26 14:30:24 UTC --- Created attachment 22162 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22162 Clang's assember Attaching the assembler output from clang, it should help understand which optimizations clang does (and improve gcc to do them as well).
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2010-10-26 14:31:47 UTC --- ;)
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #3 from Julian Andres Klode j...@jak-linux.org 2010-10-26 14:32:27 UTC --- System information: Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.5-5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --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 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.5 (Debian 4.4.5-5)
[Bug bootstrap/46018] [4.6 Regression] Bootstrap fails on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46018 --- Comment #11 from Art Haas ahaas at airmail dot net 2010-10-26 14:40:04 UTC --- I ended up trying the version posted in a follow-up mail: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02065.html The bootstrap still failed. I've now got access to a i386-pc-solaris2.11 box which also fails to bootstrap. On this system I'm configuring GCC to use the GNU assembler and Sun linker. I've also by trying this configuration on the i386-pc-solaris2.10 machine I normally use and the bootstrap fails.
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-26 14:47:12 UTC --- GCC's output is significantly faster at -O3 or without the noinline attribute
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #5 from Julian Andres Klode j...@jak-linux.org 2010-10-26 14:53:24 UTC --- (In reply to comment #4) GCC's output is significantly faster at -O3 or without the noinline attribute I just tested and at -O3, gcc-4.4 creates slow code and gcc-4.5 fast code. At -O2, both are equally fast. The clang 1.1 code at -O2 is as fast as GCC 4.5's code at -O3.
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-10-26 14:59:18 UTC --- You get this kind of speedup if the compiler knows that the result of the loop is sum=(b*(b-1)-a*(a-1))/2 In which case the timing is meaningless (it is 0.000s on my laptop), so is the ratio with the execution of the loop. The basic question is: how much the user's ignorance should be repaired by the optimizer? (A colleague of mine told me that he once audited a CFD code and found that \int_a^b dx/x was evaluated numerically instead of using log(b)-log(a)!-)
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #7 from Julian Andres Klode j...@jak-linux.org 2010-10-26 15:00:37 UTC --- (In reply to comment #5) (In reply to comment #4) GCC's output is significantly faster at -O3 or without the noinline attribute I just tested and at -O3, gcc-4.4 creates slow code and gcc-4.5 fast code. At -O2, both are equally fast. The clang 1.1 code at -O2 is as fast as GCC 4.5's code at -O3. Using gcc 4.5 with -O3 may work for the C code, but it does not optimize the C++ code posted at http://lwn.net/Articles/411776/: g++-4.5 -O3: real 0m1.608s clang++ -O2: real 0m0.003s clang++ -Os: real 0m0.003s But I guess the C++ problem might be a different one.
[Bug fortran/46166] optimization and/or removing an if(.false.) statement leads to bad results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46166 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 2010-10-26 15:00:51 UTC --- I think it would be helpful if you could reduce your test case (which is a total mess right now) to something more reasonable. Otherwise it's very hard to decide whether it is a compiler problem or a user problem and to pin down where the differences at -O0/-O1 come from.
[Bug target/46187] New: Invalid instruction suffix generated by %z
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46187 Summary: Invalid instruction suffix generated by %z Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: u...@os.inf.tu-dresden.de Created attachment 22163 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22163 Testcase The testcase compiled with -Os should produce something like the following: 4004cc: f0 80 6c 24 ff 01 lock subb $0x1,-0x1(%rsp) 4004d5: f0 66 83 6c 24 fc 02lock subw $0x2,-0x4(%rsp) 4004df: f0 48 83 6c 24 f0 03lock subq $0x3,-0x10(%rsp) This works correctly on 4.5.1 and 4.6.0. Older compilers fail as shown below. The code is supposed to emit the correct instruction suffix for SUB using %z when n is an immediate value that does not give the operand size away. Is there another way to achieve the same effect? g++-gcc-4.1.2 -Os testcase.cc -o testcase testcase.cc: In function 'int main()': testcase.cc:20: internal compiler error: in print_operand, at config/i386/i386.c:7226 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. g++-gcc-4.2.4 -Os testcase.cc -o testcase testcase.cc: In function 'int main()': testcase.cc:20: internal compiler error: in print_operand, at config/i386/i386.c:7791 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. g++-gcc-4.3.5 -Os testcase.cc -o testcase testcase.cc: Assembler messages: testcase.cc:5: Error: invalid instruction suffix for `sub' testcase.cc:5: Error: no such instruction: `subll $3,-16(%rsp)' g++-gcc-4.4.5 -Os testcase.cc -o testcase testcase.cc: Assembler messages: testcase.cc:5: Error: invalid instruction suffix for `sub' testcase.cc:5: Error: no such instruction: `subll $3,-16(%rsp)'
[Bug tree-optimization/46183] [4.6 Regression] ICE: in calc_dfs_tree, at dominance.c:396 with -O -fno-dse -fgcse -ftree-pre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46183 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.26 15:03:00 CC||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-26 15:03:00 UTC --- It is caused by revision 161655: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg6.html
[Bug target/46187] Invalid instruction suffix generated by %z
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46187 --- Comment #1 from Udo Steinberg us15 at os dot inf.tu-dresden.de 2010-10-26 15:03:01 UTC --- Bug #31768 is probably related.
[Bug fortran/46166] optimization and/or removing an if(.false.) statement leads to bad results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46166 --- Comment #4 from Steve Kargl sgk at troutmask dot apl.washington.edu 2010-10-26 15:09:37 UTC --- Janus, See comment #2. The problem is tauc is used before it is initialized. This is a bogus bug report.
[Bug fortran/46166] optimization and/or removing an if(.false.) statement leads to bad results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46166 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #5 from janus at gcc dot gnu.org 2010-10-26 15:13:14 UTC --- (In reply to comment #4) The problem is tauc is used before it is initialized. This is a bogus bug report. Why don't we just close it then?
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #8 from Julian Andres Klode j...@jak-linux.org 2010-10-26 15:25:56 UTC --- (In reply to comment #6) You get this kind of speedup if the compiler knows that the result of the loop is sum=(b*(b-1)-a*(a-1))/2 In which case the timing is meaningless (it is 0.000s on my laptop), so is the ratio with the execution of the loop. The basic question is: how much the user's ignorance should be repaired by the optimizer? (A colleague of mine told me that he once audited a CFD code and found that \int_a^b dx/x was evaluated numerically instead of using log(b)-log(a)!-) Since the optimization seems to be mostly there in -O3, it's just a matter of enabling it in -O2. I just found out that it does not optimize if you call f() via a global function pointer, it still takes 1.6 seconds despite being compiled at -O3, whereas clang can optimize it to 0.001s.
[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827 --- Comment #30 from Hans-Werner Boschmann boschmann at tp1 dot physik.uni-siegen.de 2010-10-26 15:27:27 UTC --- I've realized today, that the sample code is actually invalid. If you look at lines 488 and 681 in arguments.f03, you'll see: subroutine argument_initialize(this,arg_list,short,long,description,description_list,named_option) subroutine real_argument_initialize(this) These subroutines seem to have different interfaces, but when you have a closer look, you see that all dummy arguments are optional, except this. Besides, both this dummy arguments are type compatible. Therefore these subroutines must not share a generic interface. But that is declared in line 133: generic::initialize=argument_initialize,real_argument_initialize Could this ambiguity cause the confusion about symbols? I always have suspected this module to be the reason for the error, because I never got the error message before I wrote it. Furthermore, all error messages were somehow related to this module, even when they were generated for other modules. Nevertheless, gfortran should complain about the ambiguity. I will try to reduce the code to illustrate this point and open a new bug report.
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-26 15:28:51 UTC --- (In reply to comment #8) Since the optimization seems to be mostly there in -O3, it's just a matter of enabling it in -O2. Or if you want all optimisations, it's just a matter of using -O3 Expecting all optimisations to be done below the maximum optimisation level is ... unexpected.
[Bug middle-end/46120] [4.6 regression] g++.dg/ipa/ivinline-?.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46120 Steve Ellcey sje at cup dot hp.com changed: What|Removed |Added CC||sje at cup dot hp.com --- Comment #3 from Steve Ellcey sje at cup dot hp.com 2010-10-26 15:33:10 UTC --- I see this on all my HP-UX and Linux platforms too.
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-26 15:37:04 UTC --- -O2 -fipa-cp-clone should be in theory enough, then f would be normally cloned, assuming gcc thinks it is from a hot spot. But this is not a real-world testcase, the call from main where it happens just once for the process is not considered a hot spot.
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2010-10-26 15:42:58 UTC --- Can we please stop talking about nano and giga numbers like kids? If an optimization like complete loop unrolling is involved of course very small or large numbers can be involved, doesn't really contribute anything to the problem talking about the exact figure.
[Bug tree-optimization/46167] [4.5/4.6 Regression] ICE: SIGSEGV in flow_bb_inside_loop_p (cfgloop.c:776) with -O -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46167 --- Comment #2 from irar at gcc dot gnu.org 2010-10-26 15:53:33 UTC --- Author: irar Date: Tue Oct 26 15:53:28 2010 New Revision: 165970 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165970 Log: PR tree-optimization/46167 * tree-vect-patterns.c (vect_recog_dot_prod_pattern): Check that there is basic block for the statement. Added: trunk/gcc/testsuite/gcc.dg/vect/O-pr46167.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect.exp trunk/gcc/tree-vect-patterns.c
Re: [Bug c/46186] Clang creates code running 1600 times faster than gcc's
On Oct 26, 2010, at 7:30 AM, j...@jak-linux.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #1 from Julian Andres Klode j...@jak-linux.org 2010-10-26 14:30:24 UTC --- Created attachment 22162 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22162 Clang's assember This multiplication transformation is incorrect if the loop wraps (unsigned always wraps; never overflows). Gcc is correct in its speed. Though -O3 is faster but not because of multiplication but rather constant propatagtion. So this bug is invalid and some one should report a bug to llvm folks about this. Attaching the assembler output from clang, it should help understand which optimizations clang does (and improve gcc to do them as well).
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #12 from pinskia at gmail dot com pinskia at gmail dot com 2010-10-26 15:56:20 UTC --- On Oct 26, 2010, at 7:30 AM, j...@jak-linux.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #1 from Julian Andres Klode j...@jak-linux.org 2010-10-26 14:30:24 UTC --- Created attachment 22162 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22162 Clang's assember This multiplication transformation is incorrect if the loop wraps (unsigned always wraps; never overflows). Gcc is correct in its speed. Though -O3 is faster but not because of multiplication but rather constant propatagtion. So this bug is invalid and some one should report a bug to llvm folks about this. Attaching the assembler output from clang, it should help understand which optimizations clang does (and improve gcc to do them as well).
[Bug tree-optimization/46184] [4.6 Regression] ICE: SIGSEGV in vectorizable_reduction (tree-vect-loop.c:4067) with -O -ftree-vectorize -fno-tree-copy-prop -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46184 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.26 16:32:20 CC||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-26 16:32:20 UTC --- It is caused by revision 158157: http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00261.html
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-10-26 16:36:05 UTC --- This multiplication transformation is incorrect if the loop wraps (unsigned always wraps; never overflows). I think this is wrong: wrapping is nothing but a modulo 2^n operation (n=64 here) which works for additions and multiplications, so if there is wrapping, the result is sum=(b*(b-1)-a*(a-1))/2 modulo 2^n, i.e. correctly wrapped. On my Core2duo 2.53Ghz with -Ofast the run time is ~1.2s for elementary 2*10^9 loops or .6ns/loop or ~1.5 clock cycle per loop. For a perfect vectorization and no loop overhead, I would expect a minimum of 0.5 clock cycle per loop. If you get anything below this number, it means that the loop for (; a b; a++) sum += a; is replaced with sum=(b*(b-1)-a*(a-1))/2 (you can confirm it by checking that the timing behaves as O(len) or not). Apparently clang does this (valid) transformation while gcc don't for any options I have tried. Note that If I write such a loop, it is because I am interested by the timing of the loop, not by the result I know for more than 40 years!
[Bug lto/45736] [4.6 Regression] ICE: in cgraph_remove_unreachable_nodes, at ipa.c:245 with -flto and attribute((constructor))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45736 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2010-10-26 16:40:33 UTC --- Author: hubicka Date: Tue Oct 26 16:40:16 2010 New Revision: 165972 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165972 Log: PR middle-end/45736 * cgraph.c (cgraph_set_readonly_flag): Rename to... (cgraph_set_const_flags) ... this one; get also looping argument; clear constructor/destructor flags. (cgraph_set_pure_flag): Likewise. (cgraph_set_looping_const_or_pure_flag): Remove. (cgraph_can_remove_if_no_direct_calls_and_refs): Do not try to optimize away static ctors/dtors; it does not work on inline clones; external functions can always be rmeoved. (cgraph_will_be_removed_from_program_if_no_direct_calls): Assert on inline clones; in LTO external functions always can go. (cgraph_used_from_object_file_p): Handle EXTERNAL functions correctly. (cgraph_mark_address_taken_node): Assert that we are not taking address of inline clone. (cgraph_can_remove_if_no_direct_calls_p): We always eventually remove external functions. * ipa-cp.c (ipcp_cloning_candidate_p): Do not clone functions with address taken. (ipcp_initialize_node_lattices): Only local functions can be handled without cloning. * cgraph.h (cgraph_set_readonly_flag, cgraph_set_looping_const_or_pure_flag): Remove. (cgraph_set_const_flag): Declare. (cgraph_set_pure_flag): Update. * ipa-pure-const (propagate_pure_const, local_pure_const): Update flags setting code. * ipa.c (cgraph_remove_unreachable_nodes): Fix formating; do not look at inline clones; fix handling of external definitions. (cgraph_postorder): Do not look at inline clones in the first pass. (function_and_variable_visibility): Drop constructors/destructor flags at pure and const functions. * tree-profile.c (tree_profiling): Update. * ipa-inline.c (cgraph_clone_inlined_nodes): Always clone functions with address taken; external functions do not account to whole program size. (cgraph_decide_inlining): Likewise; do not try to inline functions already inlined. * testsuite/gcc.dg/lto/pr45736_0.c: New function. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c trunk/gcc/cgraph.h trunk/gcc/ipa-cp.c trunk/gcc/ipa-inline.c trunk/gcc/ipa-pure-const.c trunk/gcc/ipa.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-profile.c
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.26 16:59:00 CC||spop at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-26 16:59:00 UTC --- For sum += 2 or sum += b sccp handles this, so I wonder whether it couldn't handle even the sum += a case. Sebastian?
[Bug c++/46188] New: -fipa-cp removes destructor call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46188 Summary: -fipa-cp removes destructor call Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jens.mau...@gmx.net Created attachment 22164 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22164 source file to reproduce the bug In the attached source code, the destructor calls for B::char_array when destroying c2 at the end of function f are removed by the optimizer when compiling with -fipa-cp . I have removed .cfi notes in the assembly quoted below, for conciseness. bad compile: $ g++ -S playground.cxx -fverbose-asm -O2 yields (note that no operator delete[] is called on B::char_array): 159 .LEHB0: 160 callg(C const, C) # 161 .LEHE0: 162 movq24(%rsp), %rdi # c2.b_array.data, D.2822 163 testq %rdi, %rdi # D.2822 164 je .L15#, 165 calloperator delete[](void*)# 166 .L15: 167 movq16(%rsp), %rdi # c2.s.adr, D.2837 168 testq %rdi, %rdi # D.2837 169 je .L14#, 170 calloperator delete[](void*)# 171 .L14: 172 addq$48, %rsp #, 175 popq%rbx# 177 ret good compile: $ g++ -S playground.cxx -fverbose-asm -O2 -fno-ipa-cp 165 callg(C const, C) # 166 .LEHE0: 167 movq8(%rsp), %rbx # c2.b_array.data, p 168 testq %rbx, %rbx # p 169 je .L15#, 170 movq16(%rsp), %r12 # c2.b_array.size, D.2808 171 testq %r12, %r12 # D.2808 172 je .L16#, 173 xorl%ebp, %ebp # i 174 jmp .L20# 175 .p2align 4,,10 176 .p2align 3 177 .L25: 178 addq$24, %rbx #, p 179 .L20: 180 movq(%rbx), %rdi# p-char_array.data, D.2820 181 testq %rdi, %rdi # D.2820 182 je .L18#, 183 calloperator delete[](void*)# 184 .L18: 185 addq$1, %rbp#, i 186 cmpq%rbp, %r12 # i, D.2808 187 ja .L25#, 188 movq8(%rsp), %rbx # c2.b_array.data, p 189 .L16: 190 testq %rbx, %rbx # p 191 je .L15#, 192 movq%rbx, %rdi # p, 193 calloperator delete[](void*)# 194 .L15: 195 movq(%rsp), %rdi# c2.s.adr, D.2824 196 testq %rdi, %rdi # D.2824 197 je .L14#, 198 calloperator delete[](void*)# 199 .L14: 200 addq$32, %rsp #, 203 popq%rbx# 205 popq%rbp# 207 popq%r12# 209 ret Removing any one of the seemingly unrelated lines marked ##1, ##2, ##3 will produce correct compiler output. Also, messing with the Array::destruct function (e.g. use data + i instead of p, use the constants for start/end directly instead of passing via parameters) will remove the problem.
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186 --- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-10-26 17:15:31 UTC --- For sum += 2 or sum += b sccp handles this, so I wonder whether it couldn't handle even the sum += a case. 2 and b are constants while a is not. For constants you have to know that the sum is cst*nloop, while if a is incremented you have to know that it is related to nloop*(nloop+1)/2 (and if you use sum += a*a, nloop*(nloop+1)*(2*nloop+1)/6, if sum += a*a*a, nloop^2*(nloop+1)^2/4 and so on). However is it worth the work?
[Bug fortran/42647] [F03] Missed initialization/dealloc of allocatable scalar DT with allocatable component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42647 --- Comment #12 from janus at gcc dot gnu.org 2010-10-26 17:38:51 UTC --- Author: janus Date: Tue Oct 26 17:38:42 2010 New Revision: 165973 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165973 Log: 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. Added: trunk/gcc/testsuite/gfortran.dg/allocatable_scalar_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90 trunk/gcc/testsuite/gfortran.dg/class_19.f03
[Bug fortran/42647] [F03] Missed initialization/dealloc of allocatable scalar DT with allocatable component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42647 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from janus at gcc dot gnu.org 2010-10-26 17:51:30 UTC --- r165973 fixes all the deallocation trouble and the accepts-invalid problem from comment #10/#11 is being tracked by PR46017. So I think we can finally close this PR.
[Bug c/46155] Bug with generation of float.h header file on AIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155 --- Comment #12 from Dr. David Kirkby david.kirkby at onetel dot net 2010-10-26 17:59:38 UTC --- (In reply to comment #11) (In reply to comment #7) In your opinion, are IBM wrong to define fprnd_t in /usr/include/float.h? IBM's definition of fprnd_t in float.h is within #ifdef _ALL_SOURCE. I presume _ALL_SOURCE is not defined when IBM's compiler is used in ISO C conforming mode. AFAIK, adding non-standard definitions to standard header files in non-conforming modes is a common practice. The float.h that GCC installed on AIX is identical to gcc/ginclude/float.h in the GCC 4.2.4 sources. I can understand if GCC developers don't want to introduce OS-specific sections in it. Whist you can understand the developers not wanting to introduce OS-specific sections to the library, it should be realised it breaks code which will compile with the IBM compiler. IMHO, it would be sensible to preserve the IBM definitions in the file. The 'mkheaders' script is I believe written to work around what gcc considers buggy header files, yet by doing this you remove definitions that can be important on AIX systems. I can see your point about perhaps the GSL developers should use the C99 features in preference to other ones, but the GSL code is very portable, so I suspect will work with pre-C99 systems. I know GSL builds on AIX, HP-UX, FreeBSD and Cygwin - 4 less common operating systems. Anyway, I can work around this, but my own feeling is the IBM definitions should be preserved. Dave
[Bug middle-end/46120] [4.6 regression] g++.dg/ipa/ivinline-?.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46120 --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org 2010-10-26 18:14:42 UTC --- Yes, I know why this happens and actually have a prototype patch to fix it but it depends on another patch I need to get accepted first.
[Bug middle-end/46185] [4.6 Regression] gcc.dg/graphite/interchange-4.c FAILs with -fno-ipa-cp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46185 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.26 18:18:54 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-10-26 18:18:54 UTC --- It is caused by revision 163159: http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00370.html
[Bug middle-end/46181] attribute for marking things as undefined use after a function call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46181 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.10.26 18:29:33 Component|c |middle-end Summary|Feature request:|attribute for marking |free-like attribute |things as undefined use ||after a function call Ever Confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-10-26 18:29:33 UTC --- Confirmed.
[Bug c/46186] Clang creates code running 1600 times faster than gcc's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46186
--- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2010-10-26
18:43:40 UTC ---
chrec_apply is called with
{a_4(D), +, {a_4(D) + 1, +, 1}_1}_1
chrec and ~a_4(D) + b_5(D) in x.
I wonder if this can be fixed just by recognizing such special cases in
chrec_apply (after checking e.g. that it is unsigned computation instead of
signed etc.).
