[Bug ada/44340] internal error on allocation/initialization
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-05-31 06:54 --- Please attach the gnatchop-ed file. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING GCC build triplet|i686-pc-linux-gn|i686-pc-linux-gnu GCC host triplet|i686-pc-linux-gn|i686-pc-linux-gnu GCC target triplet|i686-pc-linux-gn|i686-pc-linux-gnu Summary|gcc (gnat) crash on |internal error on |allocation/initialization |allocation/initialization Version|unknown |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44340
[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm
--- Comment #14 from mikpe at it dot uu dot se 2010-05-31 07:20 --- The bootstrap comparison failure is gone on armv5tel-unknown-linux-gnueabi with gcc-4.6-20100529. Thus closing as fixed. -- mikpe at it dot uu dot se changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44255
[Bug tree-optimization/44337] [4.5/4.6 Regression] ICE: in expand_assignment, at expr.c:4276
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-31 07:59:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44337
[Bug target/44338] -mno-fused-madd causes FAIL: gcc.target/i386/sse-23.c (internal compiler error)
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-31 08:00:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44338
[Bug target/44338] -mno-fused-madd causes FAIL: gcc.target/i386/sse-23.c (internal compiler error)
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-31 08:50 ---
Reduced testcase:
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
typedef float __v4sf __attribute__ ((__vector_size__ (16)));
#pragma GCC target (3dnow,sse4,sse4a,aes,pclmul,xop,abm,popcnt,lwp)
__m128
_mm_macc_ps (__m128 __A, __m128 __B, __m128 __C)
{
return (__m128) __builtin_ia32_vfmaddps ((__v4sf)__A, (__v4sf)__B,
(__v4sf)__C);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44338
[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86
--- Comment #10 from borntraeger at de dot ibm dot com 2010-05-31 08:58 --- Created an attachment (id=20783) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20783action=view) experimental patch to have separate values for min_insn_to_prefetch_ration Changpeng, thank you for the feedback. Can you confirm that the regression was introduced by a prefetch with an unknown step or is there still a bug in the calculation of the normal prefetches (e.g. by applying the first patch that disables non-constant steps) Anyway, here is a patch that increases min_insn_to_prefetch_ratio for non-constant steps. Does that make a difference for tonto? Do you prefer other intial values? Thanks Christian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44297
[Bug target/44338] -mno-fused-madd causes FAIL: gcc.target/i386/sse-23.c (internal compiler error)
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-31 09:15 --- The problem is that all the fma4 insns are guarded with not just TARGET_FMA4, but TARGET_FMA4 TARGET_FUSED_MADD. But the builtins are guarded just with OPTION_MASK_ISA_FMA4. So, for -mno-fused-madd either we should ensure fma4intrin.h is not included (or, at least not its fma intrinsics (currently all intrinsics in the header file)) and the builtins expand to nothing, or for -mfma4 -mno-fused-madd expand the intrinsics as non-fused insns (multiplication followed by addition or similar). -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||hjagasia at gcc dot gnu dot ||org, spop at gcc dot gnu dot ||org AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44338
[Bug c++/43392] [C++0x]: segmentation fault with empty initializer list
--- Comment #4 from paolo dot carlini at oracle dot com 2010-05-31 09:29 --- Works in current 4_4-branch, 4_5-branch, and mainline. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.4.3 4.5.0 4.6.0 Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43392
[Bug libgomp/44342] New: gfortran and OpenMP: Allocate fails on nested parallelism regions
Code: - program simple_alloc_copyin use omp_lib integer, allocatable, save :: A(:) !$omp threadprivate(A) call omp_set_num_threads(2) ALLOCATE(A(2)) call omp_set_nested(.TRUE.) call omp_set_dynamic(.FALSE.) !$omp parallel !$omp parallel num_threads(2) if(.NOT.allocated(A))allocate(A(2)) !$omp end parallel !$omp parallel if(.NOT.allocated(A))print *, 'not allocated!!!' !$omp end parallel !$omp parallel copyin(A) print *, omp_get_thread_num(), ':', A !$omp end parallel !$omp end parallel end program simple_alloc_copyin - Execution: - not allocated!!! not allocated!!! Segmentation fault - In the OpenMP forum told me that it was a compiler issue. http://openmp.org/forum/viewtopic.php?f=7t=639p=3400#p3400 -- Summary: gfortran and OpenMP: Allocate fails on nested parallelism regions Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: shiv4k at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44342
[Bug libstdc++/44339] Usage of std::weak_ptr in ordered stl container (C++0x)
--- Comment #7 from jwakely dot gcc at gmail dot com 2010-05-31 10:16 --- n2637 removed comparisons on weak_ptr http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2637.pdf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44339
[Bug target/44338] -mno-fused-madd causes FAIL: gcc.target/i386/sse-23.c (internal compiler error)
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-31 10:46 --- (In reply to comment #2) The problem is that all the fma4 insns are guarded with not just TARGET_FMA4, but TARGET_FMA4 TARGET_FUSED_MADD. But the builtins are guarded just with OPTION_MASK_ISA_FMA4. So, for -mno-fused-madd either we should ensure fma4intrin.h is not included (or, at least not its fma intrinsics (currently all intrinsics in the header file)) and the builtins expand to nothing, or for -mfma4 -mno-fused-madd expand the intrinsics as non-fused insns (multiplication followed by addition or similar). Well, TARGET_FMA4 should be enough to pull in the intrinsics and let the user manually create fmas. TARGET_FUSED_MADD should guard automatic creation of fmas during combine (and thus needs to disable the insn to avoid creating it). I guess for the intrinsic use we need a UNSPEC expander then? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, hubicka at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44338
[Bug tree-optimization/44337] [4.5/4.6 Regression] ICE: in expand_assignment, at expr.c:4276
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44337
[Bug tree-optimization/44336] [4.4/4.5/4.6 Regression] ICE: verify_ssa failed: SSA_NAME_DEF_STMT is wrong with -fipa-struct-reorg -fwhole-program
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-31 10:53 --- Same ICE with -fipa-type-escape enabled in 4.4 and 4.5. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-31 10:53:15 date|| Summary|[4.6 Regression] ICE: |[4.4/4.5/4.6 Regression] |verify_ssa failed: |ICE: verify_ssa failed: |SSA_NAME_DEF_STMT is wrong |SSA_NAME_DEF_STMT is wrong |with -fipa-struct-reorg - |with -fipa-struct-reorg - |fwhole-program |fwhole-program Target Milestone|--- |4.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44336
[Bug libgomp/44342] gfortran and OpenMP: Allocate fails on nested parallelism regions
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-31 11:51 --- This is not a compiler bug. See OpenMP 3.0 spec, 2.9.2, page 82, lines 9-18. The guarantee that you are looking at the same thread is there only for parallels not nested in another parallel, with nested parallels there is no such guarantee. Note that you use num_threads(2) on the first nested parallel, so even if the outer parallel is removed, the program would be guaranteed to work only if it decides to use just 2 threads (say with OMP_NUM_THREADS=2 etc.). -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44342
[Bug middle-end/44337] [4.5/4.6 Regression] ICE: in expand_assignment, at expr.c:4276
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-31 11:56 --- Created an attachment (id=20784) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20784action=view) gcc46-pr44337.patch Untested fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44337
[Bug libgomp/44342] gfortran and OpenMP: Allocate fails on nested parallelism regions
--- Comment #2 from shiv4k at gmail dot com 2010-05-31 11:58 --- So, it is not possible to COPYIN in a nested region an allocatable member? -- shiv4k at gmail dot com changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44342
[Bug libgomp/44342] gfortran and OpenMP: Allocate fails on nested parallelism regions
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-31 12:00 --- Right. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44342
[Bug target/44338] -mno-fused-madd causes FAIL: gcc.target/i386/sse-23.c (internal compiler error)
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-31 12:12 --- 20 out of the 40 TARGET_FMA4 patterns use UNSPEC_FMA4_INTRINSIC, and those are the ones actually used by the intrinsics. So, perhaps the only change that is needed is to drop TARGET_FUSED_MADD on those 20 patterns and leave it on the other 20 patterns. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44338
[Bug middle-end/44308] ranlib: file: libbackend
--- Comment #4 from jay dot krell at cornell dot edu 2010-05-31 12:14 --- Here is the fix for insn-peep.o (against 4.3, granted): diff -u -r1.5 genpeep.c --- gcc/gcc/genpeep.c 14 Apr 2008 12:48:21 - 1.5 +++ gcc/gcc/genpeep.c 31 May 2010 12:14:37 - @@ -424,6 +424,7 @@ printf (rtx peep_operand[%d];\n, max_opno + 1); printf (#endif\n); + printf (\nchar quash_apple_randlib_warning_peephole;\n); fflush (stdout); return (ferror (stdout) != 0 ? FATAL_EXIT_CODE : SUCCESS_EXIT_CODE); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44308
[Bug target/44338] -mno-fused-madd causes FAIL: gcc.target/i386/sse-23.c (internal compiler error)
--- Comment #5 from jakub at gcc dot gnu dot org 2010-05-31 12:26 --- Created an attachment (id=20785) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20785action=view) gcc46-pr44338.patch That seems to work. Untested patch attached. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44338
[Bug ada/44340] internal error on allocation/initialization
--- Comment #2 from marc dot criley at gmail dot com 2010-05-31 14:01 --- Created an attachment (id=20786) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20786action=view) Bug triggering source code (gnatchoppable) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44340
[Bug target/44161] __attribute__((__target__)) resets pic flag causing spurious warnings
--- Comment #3 from ktietz at gcc dot gnu dot org 2010-05-31 14:07 --- Subject: Bug 44161 Author: ktietz Date: Mon May 31 14:06:41 2010 New Revision: 160070 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160070 Log: 2010-05-31 Kai Tietz kai.ti...@onevision.com PR target/44161 * config/i386/cygming.h (SUBTARGET_OVERRIDE_OPTIONS): Handle flag_pic. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/cygming.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44161
[Bug target/44161] __attribute__((__target__)) resets pic flag causing spurious warnings
-- ktietz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ktietz at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-31 14:11:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44161
[Bug testsuite/44343] New: malloc check in libstdc++-v3/testsuite/22_locale/codecvt/unshift/char/1.cc
Hi there, I have Fedora 13, just installed gcc 4.5.0 and running the make check command with export MALLOC_CHECK_=1 (or 2 or 3) I get the summary. This is at line 77 of 1.cc: delete [] c_arr; The malloc check message I receive is free(): invalid pointer I have no idea if it is a libstdc++ bug or just a bug in 1.cc. Can you please look into it? Best regards Vittorio Zecca -- Summary: malloc check in libstdc++- v3/testsuite/22_locale/codecvt/unshift/char/1.cc Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44343
[Bug target/44161] __attribute__((__target__)) resets pic flag causing spurious warnings
--- Comment #4 from ktietz at gcc dot gnu dot org 2010-05-31 14:16 --- Subject: Bug 44161 Author: ktietz Date: Mon May 31 14:16:21 2010 New Revision: 160072 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160072 Log: 2010-05-31 Kai Tietz kai.ti...@onevision.com Merged from trunk PR target/44161 * config/i386/cygming.h (SUBTARGET_OVERRIDE_OPTIONS): Handle flag_pic. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/i386/cygming.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44161
[Bug target/44161] __attribute__((__target__)) resets pic flag causing spurious warnings
--- Comment #5 from ktietz at gcc dot gnu dot org 2010-05-31 14:17 --- Merged back to 4.5 branch at revision 160072. Fixed. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44161
[Bug testsuite/44343] malloc check in libstdc++-v3/testsuite/22_locale/codecvt/unshift/char/1.cc
--- Comment #1 from amonakov at gcc dot gnu dot org 2010-05-31 14:23 --- Yes, it's a bug in 1.cc that was fixed for 4.6. -- amonakov at gcc dot gnu dot org changed: What|Removed |Added CC||amonakov at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44343
[Bug testsuite/44343] malloc check in libstdc++-v3/testsuite/22_locale/codecvt/unshift/char/1.cc
--- Comment #2 from paolo dot carlini at oracle dot com 2010-05-31 14:28 --- Alexander, please backport the fix to 4_5-branch and close the PR. Thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-31 14:28:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44343
[Bug fortran/44344] New: compilation error with function array
I want to calculate a multivariable function func(x) and its gradient dfunc(x), where x is a vector. The gradient dfunc(x) is calculated with finite difference method. I defined two modules and a calling program as follows: 1. Mod_func: module to calculate the function values at x 2. Mod_dfunc: module to calculate the gradient at x. Since numerical finite difference formula are used to obtain dfunc(x), dfunc(x) needs to call func(x). 3. drive: calling program If dfunc is not included, and correspondingly not called from the calling program(drive.f90), it works fine. When dfunc is included, this causes compilation error: $ gfortran -c func.f90 dfunc.f90 drive.f90 drive.f90:8.14: real ::dfunc(ndim) 1 Error: Cannot change attributes of USE-associated symbol dfunc at (1) The codes: Module mod_func ! Purpose: To calculate multivariable function func(x), x is a vector Contains FUNCTION func(x) IMPLICIT NONE REAL, DIMENSION(:), INTENT(IN) :: x REAL :: func integer::i,n n=size(x) func=0 do i=1,n ! a simple multivariable function: func(x) = x1**2 + x2**2 + ... func= func+ x(i)**2 end do END FUNCTION func End module mod_func Module mod_dfunc ! Purpose: To calculate gradient at x by finite difference, where x is a vector Contains FUNCTION dfunc(x) use mod_func ! To calculate dfunc(x), we need ! function values func(x) and func(x+äx) ! ä is a small scalar implicit none REAL, DIMENSION(:), INTENT(IN) :: x REAL, DIMENSION(size(x)) :: dfunc real, dimension(:),allocatable:: e! e is the unit vector real :: del ! del == ä integer:: i,n del=sqrt(epsilon(x(1))) n=size(x) allocate(e(n)) do i=1,n e=0. e(i)=1. !central difference formula dfunc(i)=(func(x+del*e) - func(x-del*e))/(2.*del) end do deallocate(e) END FUNCTION dfunc End module mod_dfunc program drive use mod_func use mod_dfunc implicit none integer,parameter::ndim=2 real :: x(ndim) ! 2 variables, (x1,x2) real ::func real ::dfunc(ndim) x=(/1.0,3./) write(*,*) 'x:',x write(*,*) 'function value:',func(x) write(*,*) 'function gradiet:',dfunc(x) end program drive -- Summary: compilation error with function array Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yyxt at hotmail dot com GCC build triplet: build=x86_64-linux-gnu GCC host triplet: host=x86_64-linux-gnu GCC target triplet: Target: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44344
[Bug fortran/44344] compilation error with function array
--- Comment #1 from yyxt at hotmail dot com 2010-05-31 14:57 --- error is in the code,not with the compiler -- yyxt at hotmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44344
[Bug tree-optimization/44182] [4.5/4.6 Regression] -fcompare-debug failure (length) with -O1
--- Comment #7 from jakub at gcc dot gnu dot org 2010-05-31 15:38 --- Subject: Bug 44182 Author: jakub Date: Mon May 31 15:38:35 2010 New Revision: 160074 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160074 Log: PR tree-optimization/44182 * tree-inline.c (copy_edges_for_bb): Don't split bb if a stmt that newly needs to end a bb is followed by debug stmts, instead return true from the function at the end. (maybe_move_debug_stmts_to_successors): New function. (copy_cfg_body): Call it if copy_edges_for_bb returned true. * g++.dg/debug/pr44182.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/pr44182.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44182
[Bug tree-optimization/44182] [4.5/4.6 Regression] -fcompare-debug failure (length) with -O1
--- Comment #8 from jakub at gcc dot gnu dot org 2010-05-31 15:40 --- Subject: Bug 44182 Author: jakub Date: Mon May 31 15:40:32 2010 New Revision: 160075 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160075 Log: PR tree-optimization/44182 * tree-inline.c (copy_edges_for_bb): Don't split bb if a stmt that newly needs to end a bb is followed by debug stmts, instead return true from the function at the end. (maybe_move_debug_stmts_to_successors): New function. (copy_cfg_body): Call it if copy_edges_for_bb returned true. * g++.dg/debug/pr44182.C: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/debug/pr44182.C Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44182
[Bug middle-end/44337] [4.5/4.6 Regression] ICE: in expand_assignment, at expr.c:4276
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-31 15:42 --- Subject: Bug 44337 Author: jakub Date: Mon May 31 15:42:10 2010 New Revision: 160076 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160076 Log: PR middle-end/44337 * expr.c (expand_assignment): Don't store anything for out-of-bounds array accesses with non-MEM. * gcc.dg/pr44337.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr44337.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44337
[Bug middle-end/44337] [4.5/4.6 Regression] ICE: in expand_assignment, at expr.c:4276
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-31 15:45 --- Subject: Bug 44337 Author: jakub Date: Mon May 31 15:45:06 2010 New Revision: 160077 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160077 Log: PR middle-end/44337 * expr.c (expand_assignment): Don't store anything for out-of-bounds array accesses with non-MEM. * gcc.dg/pr44337.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr44337.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/expr.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44337
[Bug tree-optimization/44182] [4.5/4.6 Regression] -fcompare-debug failure (length) with -O1
--- Comment #9 from jakub at gcc dot gnu dot org 2010-05-31 15:46 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44182
[Bug middle-end/44337] [4.5/4.6 Regression] ICE: in expand_assignment, at expr.c:4276
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-31 15:47 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44337
[Bug fortran/44345] New: ICE in fold_convert_loc
The attached source provokes the summary: pointer p target q q(i)=i p=q(110) print *,p end Best regards Vittorio Zecca -- Summary: ICE in fold_convert_loc Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44345
[Bug fortran/44346] New: gfortran accepts illegal arguments to intrinsics
gfortran should not accept the following: character s,ss(1),pad(1),order(1) integer nn(7) c gfortran should complain that POS and LEN are negative print *,ibits(i,-1,-1) c POS+LENBIT_SIZE(i) print *,ibits(i,100,100) c 30+332 call mvbits(n,30,3,n,1) c 31+232 call mvbits(n,30,2,n,31) c LEN negative call mvbits(n,30,-2,n,30) c TOPOS negative call mvbits(n,30,2,n,-3) c FROMPOS negative call mvbits(n,-1,2,n,3) end Best regards Vittorio Zecca -- Summary: gfortran accepts illegal arguments to intrinsics Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44346
[Bug fortran/44347] New: gfortran segmentation violation in gfc_conv_scalarized_array_ref
The following provokes the summary: dimension ip(1),ir(1) print *,selected_real_kind(ip,i) print *,selected_real_kind(i,ir) end Best regards Vittorio Zecca -- Summary: gfortran segmentation violation in gfc_conv_scalarized_array_ref Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44347
[Bug bootstrap/44335] [4.6 regression] gcc-4.6-20100529 java bootstrap failure on arm-linux-gnueabi
--- Comment #2 from mikpe at it dot uu dot se 2010-05-31 16:20 --- Steven's patch in r160039 did get me a past the error in java/except.c, however then the bootstrap dies a few files later with: /home/mikpe/gcc-4.6-20100529/gcc/java/jcf-parse.c: In function 'handle_constant': /home/mikpe/gcc-4.6-20100529/gcc/java/jcf-parse.c:565:9: error: implicit declaration of function 'arm_float_words_big_endian' [-Werror=implicit-function-declaration] cc1: all warnings being treated as errors make[3]: *** [java/jcf-parse.o] Error 1 make[3]: Leaving directory `/home/mikpe/objdir46/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/mikpe/objdir46' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/mikpe/objdir46' make: *** [bootstrap] Error 2 -- mikpe at it dot uu dot se changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44335
[Bug fortran/44348] New: ICE in build_function_decl
The following provokes the summary: subroutine sub(ff) contains subroutine ff end subroutine end Best regards Vittorio Zecca -- Summary: ICE in build_function_decl Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44348
[Bug fortran/44349] New: ICE Bad IO basetype (1)
The following provokes the summary: print *,null() end Best regards Vittorio Zecca -- Summary: ICE Bad IO basetype (1) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44349
[Bug fortran/44350] New: accepts illegal fortran in BLOCK DATA
The following provokes the summary: block data common x c illegal f(x)=x c illegal interface end interface c illegal 1 format() end Best regards Vittorio Zecca -- Summary: accepts illegal fortran in BLOCK DATA Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44350
[Bug fortran/44351] New: ICE in gfc_assign_data_value_range
The following provokes the summary: INTEGER TYPE ( -20 : 20 , 0: 40 ) DATA TYPE /1681 * 5 / DATA TYPE( -20,0) / 7 / end Best regards Vittorio Zecca -- Summary: ICE in gfc_assign_data_value_range Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44351
[Bug fortran/44346] gfortran accepts illegal arguments to intrinsics
--- Comment #1 from kargl at gcc dot gnu dot org 2010-05-31 16:29 --- Thanks for the bug report. Technically, the prohibition of nonnegative is on the programmer, and as such the code is illegal. gfortran can do anything it wants with the program including starting world war iii. OTOH, this appears to be a quality-of-implementation issue, and if gfortran can diagnosis the problem, and error should be emitted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44346
[Bug fortran/44352] New: ICE in string_to_single_character
The following provokes the summary: implicit real*8 (a-h,o-z) character*32 ddname,dname dname(x)= 'h810 e=0.01 ' ddname=dname(0.d0) END Best regards Vittorio Zecca -- Summary: ICE in string_to_single_character Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44352
[Bug fortran/44353] New: rejects legal fortran
The following provokes the summary: subroutine sub(i) intent(in) i integer ii(10) data (ii(i),i=1,10) /10*0/ ! here the scope of i is the data statement end Best regards Vittorio Zecca -- Summary: rejects legal fortran Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44353
[Bug fortran/44354] New: incorrect output at run time
The following provokes the summary, must be compiled and run: c gfortran run time only displays 1 I=5 print *,(/(i,i=1,I)/) end Best regards Vittorio Zecca -- Summary: incorrect output at run time Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zeccav at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug testsuite/44343] malloc check in libstdc++-v3/testsuite/22_locale/codecvt/unshift/char/1.cc
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-31 16:38 --- I applied the fix to 4_5-branch too: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg01139.html -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44343
[Bug fortran/44345] ICE in fold_convert_loc
--- Comment #1 from mikael at gcc dot gnu dot org 2010-05-31 16:59 --- I think the code is invalid as it violates : C554 An entity with the TARGET attribute shall be a variable. Confirmed. -- mikael at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Known to fail||4.4.4 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-05-31 16:59:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44345
[Bug fortran/44347] gfortran segmentation violation in gfc_conv_scalarized_array_ref
--- Comment #1 from mikael at gcc dot gnu dot org 2010-05-31 17:14 --- Works with trunk. -- mikael at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||ice-on-valid-code Known to fail||4.4.4 Known to work||4.6.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44347
[Bug fortran/44346] gfortran accepts illegal arguments to intrinsics
--- Comment #2 from kargl at gcc dot gnu dot org 2010-05-31 17:22 --- I have a patch for the IBITS() portion of the problem. -- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-31 17:22:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44346
[Bug c/44355] New: \ at the end of a comment
Hi!
We've seen a strange bug at work today.
Simply copy/paste this code:
#include stdio.h
int main()
{
printf(Hello\n); // \
printf(World\n);
return 0;
}
Verify there is a space after the backspace.
The compilation goes well (there is a warning though with -Wall), but at the
execution you'll only see Hello. The word World has been wiped out by the
\.
It seems like the begin and end spaces on the line are trimmed and so it
doesn't detect the character '\ '.
If it's the standard, then it's not a bug. But I must admit I'm not sure...
Thanks,
Romain
--
Summary: \ at the end of a comment
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: romain dot failliot at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44355
[Bug fortran/34547] NULL(): Fortran 2003 changes, accepts invalid, ICE on invalid
--- Comment #2 from mikael at gcc dot gnu dot org 2010-05-31 17:36 --- *** Bug 44349 has been marked as a duplicate of this bug. *** -- mikael at gcc dot gnu dot org changed: What|Removed |Added CC||zeccav at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34547
[Bug fortran/44349] ICE Bad IO basetype (1)
--- Comment #1 from mikael at gcc dot gnu dot org 2010-05-31 17:36 --- *** This bug has been marked as a duplicate of 34547 *** -- mikael at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44349
[Bug fortran/44354] incorrect output at run time
--- Comment #1 from mikael at gcc dot gnu dot org 2010-05-31 17:43 --- Note that fortran is case insensitive, ie i and I refer to the same variable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug fortran/44346] gfortran accepts illegal arguments to intrinsics
--- Comment #3 from kargl at gcc dot gnu dot org 2010-05-31 17:51 --- I have a complete patch with the mvbits checking done. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44346
[Bug fortran/44347] gfortran segmentation violation in gfc_conv_scalarized_array_ref
--- Comment #2 from dominiq at lps dot ens dot fr 2010-05-31 17:56 --- I think the code is invalid: (1) i, ip, ir are used unitialized; (2) the arguments of selected_real_kind should be scalar integer. So this pr is probably ICE-on-invalid for 4.4 and 4.5(?) and accept invalid for 4.6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44347
[Bug fortran/44354] incorrect output at run time
--- Comment #2 from dominiq at lps dot ens dot fr 2010-05-31 18:01 --- Note that fortran is case insensitive, ... Indeed, but I think the implied do loop should still go from 1 to 5. Note that if I print 'i' after the loop I get 5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug c/44355] \ at the end of a comment
--- Comment #1 from paolo dot carlini at oracle dot com 2010-05-31 18:02 --- There is nothing strange about this, the backslash simply means that the comment, which start after the //, continues to the next line, thus the second printf is part of the comment. Just use -E to see that the preprocessor removes the second printf as any other comment. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44355
[Bug fortran/44354] incorrect output at run time
--- Comment #3 from mikael at gcc dot gnu dot org 2010-05-31 18:04 --- OK, it seems gfortran is wrong here. The 4.8 section (Construction of array values) says : /If an ac-value is an ac-implied-do, it is expanded to form a sequence of elements under the control of the ac-do-variable, as in the DO construct (8.1.6.6)./ And in the DO construct the number of iterations shall be evaluated before execution. Confirmed. However, having this in real world codes seems like the best way to confuse people. -- mikael at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.4.4 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-05-31 18:04:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug c/44355] \ at the end of a comment
--- Comment #2 from romain dot failliot at gmail dot com 2010-05-31 18:10 --- Even if there is a space after the '\'? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44355
[Bug middle-end/44356] New: [4.6 regression] FAIL: gcc.dg/tree-ssa/loadpre6.c
On Linux/x86, revision 160052 gave FAIL: gcc.dg/tree-ssa/loadpre6.c scan-tree-dump-times pre Eliminated: 2 1 Revision 160048 is OK. -- Summary: [4.6 regression] FAIL: gcc.dg/tree-ssa/loadpre6.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44356
[Bug fortran/44347] gfortran segmentation violation in gfc_conv_scalarized_array_ref
--- Comment #3 from mikael at gcc dot gnu dot org 2010-05-31 18:10 --- (In reply to comment #2) I think the code is invalid: (1) i, ip, ir are used unitialized; (2) the arguments of selected_real_kind should be scalar integer. So this pr is probably ICE-on-invalid for 4.4 and 4.5(?) and accept invalid for 4.6. The problem was really on the segmentation violation I think. One can reopen to track the absence of errors for (1) and (2). I leave this up to you (or others). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44347
[Bug c/44355] \ at the end of a comment
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-31 18:19 --- -Wall tells you indeed that you have a multi-line comment, just \ triggers it, the space doesn't make any difference. And if you have a multi-line comment, what else you can expect for the output of the pre-processor? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44355
[Bug fortran/44354] incorrect output at run time
--- Comment #4 from kargl at gcc dot gnu dot org 2010-05-31 18:33 --- (In reply to comment #2) Note that fortran is case insensitive, ... Indeed, but I think the implied do loop should still go from 1 to 5. Note that if I print 'i' after the loop I get 5. Of course it prints 5. The 'i' in the do-loop has the scope of the implied-do-loop. The 'I' in the program has the scope of the program. laptop:kargl[247] cat ui.f90 integer j(4) I=5 j = 42 j = (/(i,i=1,I-1)/) print '(A,I0,A,4(I0,1X))', 'I = ', I, ' j = ', j end laptop:kargl[248] gfc4x -o z -fdump-tree-original ui.f90 laptop:kargl[249] ./z I = 5 j = 0 134516008 0 0 The question becomes whether the 'I' in the implied-do-loop is being used uninitialized. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug fortran/44345] ICE in fold_convert_loc
--- Comment #2 from zeccav at gmail dot com 2010-05-31 18:37 --- Subject: Re: ICE in fold_convert_loc In that case gfortran should emit an error message, but it should not crash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44345
[Bug c/44355] \ at the end of a comment
--- Comment #4 from romain dot failliot at gmail dot com 2010-05-31 18:39 --- I totally understand that the \ at the end of a line extends the comment to the other line, but I thought this was only if the '\' is the very last character of this line. What I try to understand is that if it's also the standard behavior when the line ends with \ . Because, to me, \ is an escape sequence (well that was how we used it at work). But again, I might be totally wrong. I'm just trying to be sure you understood my point. It's all about the tailing space. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44355
[Bug libstdc++/43820] [4.4/4.5/4.6 Regression] auto_ptr used with incomplete type no longer triggers warning
--- Comment #21 from paolo at gcc dot gnu dot org 2010-05-31 18:41 --- Subject: Bug 43820 Author: paolo Date: Mon May 31 18:41:33 2010 New Revision: 160082 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160082 Log: 2010-05-31 Jonathan Wakely jwakely@gmail.com PR libstdc++/43820 * include/bits/shared_ptr_base.h: Require complete type. * include/tr1/shared_ptr.h: Likewise. * testsuite/20_util/shared_ptr/cons/43820.cc: New. * testsuite/tr1/2_general_utilities/shared_ptr/cons/43820.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/43820.cc trunk/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/cons/43820.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/shared_ptr_base.h trunk/libstdc++-v3/include/tr1/shared_ptr.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
[Bug ada/44340] internal error on allocation/initialization
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-05-31 18:47 --- Thanks. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.5 4.4.3 4.5.0 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-05-31 18:47:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44340
[Bug middle-end/44356] [4.6 regression] FAIL: gcc.dg/tree-ssa/loadpre6.c
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-31 18:51 --- It is caused by revision 160051: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg01110.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44356
[Bug fortran/44354] incorrect output at run time
--- Comment #5 from dominiq at lps dot ens dot fr 2010-05-31 19:24 --- The question becomes whether the 'I' in the implied-do-loop is being used uninitialized. From comment #3, I think the 'i' in i,i= should not be the same as the 'i' in =1,i. Confirmed. However, having this in real world codes seems like the best way to confuse people. Agreed!-) I am always baffled by the users' talent to make their life miserable. Nevertheless the compiler should follow the standard, i.e., from my understanding of the construct, print the 1 to 5 sequence. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug target/44338] -mno-fused-madd causes FAIL: gcc.target/i386/sse-23.c (internal compiler error)
--- Comment #6 from jakub at gcc dot gnu dot org 2010-05-31 19:42 --- Subject: Bug 44338 Author: jakub Date: Mon May 31 19:42:07 2010 New Revision: 160083 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160083 Log: PR target/44338 * config/i386/sse.md (fma4i_fmaddmode4256, fma4i_fmsubmode4256, fma4i_fnmaddmode4256, fma4i_fnmsubmode4256, fma4i_fmaddmode4, fma4i_fmsubmode4, fma4i_fnmaddmode4, fma4i_fnmsubmode4, fma4i_vmfmaddmode4, fma4i_vmfmsubmode4, fma4i_vmfnmaddmode4, fma4i_vmfnmsubmode4, fma4i_fmaddsubv8sf4, fma4i_fmaddsubv4df4, fma4i_fmaddsubv4sf4, fma4i_fmaddsubv2df4, fma4i_fmsubaddv8sf4, fma4i_fmsubaddv4df4, fma4i_fmsubaddv4sf4, fma4i_fmsubaddv2df4): Guard only with TARGET_FMA4 instead of TARGET_FMA4 TARGET_FUSED_MADD. * gcc.target/i386/sse-24.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/sse-24.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44338
[Bug target/44338] -mno-fused-madd causes FAIL: gcc.target/i386/sse-23.c (internal compiler error)
--- Comment #7 from jakub at gcc dot gnu dot org 2010-05-31 19:43 --- Subject: Bug 44338 Author: jakub Date: Mon May 31 19:43:11 2010 New Revision: 160084 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160084 Log: PR target/44338 * config/i386/sse.md (fma4i_fmaddmode4256, fma4i_fmsubmode4256, fma4i_fnmaddmode4256, fma4i_fnmsubmode4256, fma4i_fmaddmode4, fma4i_fmsubmode4, fma4i_fnmaddmode4, fma4i_fnmsubmode4, fma4i_vmfmaddmode4, fma4i_vmfmsubmode4, fma4i_vmfnmaddmode4, fma4i_vmfnmsubmode4, fma4i_fmaddsubv8sf4, fma4i_fmaddsubv4df4, fma4i_fmaddsubv4sf4, fma4i_fmaddsubv2df4, fma4i_fmsubaddv8sf4, fma4i_fmsubaddv4df4, fma4i_fmsubaddv4sf4, fma4i_fmsubaddv2df4): Guard only with TARGET_FMA4 instead of TARGET_FMA4 TARGET_FUSED_MADD. * gcc.target/i386/sse-24.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/sse-24.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/i386/sse.md branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44338
[Bug target/44338] -mno-fused-madd causes FAIL: gcc.target/i386/sse-23.c (internal compiler error)
--- Comment #8 from jakub at gcc dot gnu dot org 2010-05-31 19:43 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44338
[Bug fortran/44354] incorrect output at run time
--- Comment #6 from kargl at gcc dot gnu dot org 2010-05-31 20:02 --- (In reply to comment #5) The question becomes whether the 'I' in the implied-do-loop is being used uninitialized. From comment #3, I think the 'i' in i,i= should not be the same as the 'i' in =1,i. Well, it still comes back to scope. The implied-do-loop is different from integer j(5) I=5 j = 42 do i = 1, I j(i) = i end do print '(A,I0,A,5(I0,1X))', 'I = ', I, ' j = ', j end because in the above 'i' and 'I' are in the same scoping unit. If you write 'i = 5; j = [(i,i=1,I)]' then the 'i' here is in a different scoping unit. I agree that the scalar-int-expr '1' and 'I' need to be evaluated to establish the the loop start and stop values. The question again based on scoping unit is whether 'I' is uninitialized. Confirmed. However, having this in real world codes seems like the best way to confuse people. Agreed!-) I am always baffled by the users' talent to make their life miserable. Nevertheless the compiler should follow the standard, i.e., from my understanding of the construct, print the 1 to 5 sequence. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug fortran/36928] array temporary for interleaving assignment
--- Comment #13 from tkoenig at gcc dot gnu dot org 2010-05-31 20:22 --- Subject: Bug 36928 Author: tkoenig Date: Mon May 31 20:22:10 2010 New Revision: 160085 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160085 Log: 2010-05-31 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/36928 * dependency.c (gfc_check_section_vs_section): Check for interleaving array assignments without conflicts. 2010-05-31 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/36928 * gfortran.dg/dependency_27.f90: New test. * gfortran.dg/array_assign_1.F90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_assignment_1.F90 trunk/gcc/testsuite/gfortran.dg/dependency_27.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36928
[Bug ada/44340] internal error on allocation/initialization
--- Comment #4 from marc dot criley at gmail dot com 2010-05-31 20:31 --- The line triggering this bug may very well be flagged as a compilation error, so it's not necessarily a concern if a fixed version of the compiler designates it as such. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44340
[Bug fortran/44354] incorrect output at run time
--- Comment #7 from mikael at gcc dot gnu dot org 2010-05-31 21:31 --- (In reply to comment #6) because in the above 'i' and 'I' are in the same scoping unit. I couldn't find what mandates in the standard that i and I are in a different scoping unit/are different variables. Are they ? If you write 'i = 5; j = [(i,i=1,I)]' then the 'i' here is in a different scoping unit. I agree that the scalar-int-expr '1' and 'I' need to be evaluated to establish the the loop start and stop values. The question again based on scoping unit is whether 'I' is uninitialized. How could it be ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug fortran/44354] incorrect output at run time
--- Comment #8 from mikael at gcc dot gnu dot org 2010-05-31 21:33 --- Created an attachment (id=20787) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20787action=view) draft patch This makes loop bounds evaluation before the internal variable substitution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug fortran/44354] incorrect output at run time
--- Comment #9 from zeccav at gmail dot com 2010-05-31 21:37 --- Subject: Re: incorrect output at run time In my example 'i' is local to the array constructor, while 'I' is global and is initialized with value 5, so that the statement should display '1 2 3 4 5'. I agree that this is a pathological example, but still gfortran should follow the standard and output the correct data. 2010/5/31, mikael at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org: --- Comment #7 from mikael at gcc dot gnu dot org 2010-05-31 21:31 --- (In reply to comment #6) because in the above 'i' and 'I' are in the same scoping unit. I couldn't find what mandates in the standard that i and I are in a different scoping unit/are different variables. Are they ? If you write 'i = 5; j = [(i,i=1,I)]' then the 'i' here is in a different scoping unit. I agree that the scalar-int-expr '1' and 'I' need to be evaluated to establish the the loop start and stop values. The question again based on scoping unit is whether 'I' is uninitialized. How could it be ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug fortran/44354] incorrect output at run time
--- Comment #10 from mikael at gcc dot gnu dot org 2010-05-31 21:39 ---
(In reply to comment #6)
integer j(5)
I=5
j = 42
do i = 1, I
j(i) = i
end do
print '(A,I0,A,5(I0,1X))', 'I = ', I, ' j = ', j
end
because in the above 'i' and 'I' are in the same scoping unit.
If you write 'i = 5; j = [(i,i=1,I)]' then the 'i' here is in
a different scoping unit. I agree that the scalar-int-expr
'1' and 'I' need to be evaluated to establish the the loop
start and stop values. The question again based on scoping
unit is whether 'I' is uninitialized.
Even if 'i' and 'I' are in different scoping unit, there is nothing unitialized
:
('i' is the external 'I', and 'ii' the internal one)
integer j(5)
I=5
j = 42
do ii = 1, I
j(ii) = ii
end do
print '(A,I0,A,5(I0,1X))', 'I = ', I, ' j = ', j
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug fortran/44354] incorrect output at run time
--- Comment #11 from kargl at gcc dot gnu dot org 2010-05-31 21:54 --- (In reply to comment #7) (In reply to comment #6) because in the above 'i' and 'I' are in the same scoping unit. I couldn't find what mandates in the standard that i and I are in a different scoping unit/are different variables. Are they ? If you write 'i = 5; j = [(i,i=1,I)]' then the 'i' here is in a different scoping unit. I agree that the scalar-int-expr '1' and 'I' need to be evaluated to establish the the loop start and stop values. The question again based on scoping unit is whether 'I' is uninitialized. How could it be ? I don't understand what you are asking. integer j(5) I = 5 j = (/ (i,i=1,I) /) ! (i,i=m1,m2) for discussion below end 'I' in line 2 is in the scope of the main program. 'i' in line 3 is in the scope of the implied-do-loop. 'I' in line 2 is not the same as 'i' in line 3. The only thing that 'i' in line 3 gets from 'I' in line 2 is its type and kind type parameter. When 'i' in line 3 comes into scope, does 'I' in the m2 become undefined? I can't find anything in the standard that states that it becomes undefined and I can't find anywhere that states that it is still defined to have a value of 5 in the evaluation of m2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug fortran/44345] ICE in fold_convert_loc
--- Comment #3 from kargl at gcc dot gnu dot org 2010-05-31 22:20 --- Interestingly, if one does not use implicit type, one finds that the following compiles: integer, pointer :: p integer, target :: q q(i)=i p=q(110) print *,p end and integer, pointer :: p integer, target :: q integer i q(i)=i p=q(110) print *,p end and real, pointer :: p real, target :: q real i q(i)=i p=q(110.) print *,p end Finally, this one does not compile real, pointer :: p real, target :: q integer i q(i)=i p=q(110) print *,p end laptop:kargl[218] gfc4x -o z t.f90 ./z t.f90: In function 'MAIN__': t.f90:5:0: internal compiler error: in fold_convert_loc, at fold-const.c:1920 Please submit a full bug report, with preprocessed source if appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44345
[Bug fortran/44354] incorrect output at run time
--- Comment #12 from kargl at gcc dot gnu dot org 2010-05-31 22:47 --- (In reply to comment #8) Created an attachment (id=20787) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20787action=view) [edit] draft patch This makes loop bounds evaluation before the internal variable substitution. BTW, I believe your patch is correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug c++/41194] __attribute__ ((__gnu_inline__)) yields undefined reference when compiled with -O0, but not with -O1
--- Comment #3 from jonny+bg at mail dot hfa3 dot org 2010-05-31 23:41
---
For clarity, a smaller test is: __inline __attribute__ ((gnu_inline)) void
func () { } int main() { func(); return 0; } $ g++ foo.cpp /tmp/cc31L8fw.o: In
function `main': foo.cpp:(.text+0x5): undefined reference to `func()' collect2:
ld returned 1 exit status Most people who hit this bug are likely using gperf.
$ gperf -N func . . . #ifdef __GNUC__ __inline #if defined
__GNUC_STDC_INLINE__ || defined __GNUC_GNU_INLINE__ __attribute__
((__gnu_inline__)) #endif #endif const char * func (str, len) . . . $ gperf -N
func -L C++ # will and avoid this bug :-) but also renames func to
Perfect_Hash::func :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41194
[Bug fortran/44354] incorrect output at run time
--- Comment #13 from kargl at gcc dot gnu dot org 2010-05-31 23:44 --- Due to my confusion over the scope of 'i' and 'I', I posted to c.l.f. As usual Richard Maine pieced through the standard's language. http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/1f88cd2dec855d73# Richard's explanation states the code is illegal. I've removed the wrong-code keyword. The only point left to discuss is whether Mikael patch should be applied. It will give the results that Vittorio wants. Personally, I would rather issue an error. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||sgk at troutmask dot apl dot ||washington dot edu Keywords|wrong-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug c++/41194] __attribute__ ((__gnu_inline__)) yields undefined reference when compiled with -O0, but not with -O1
--- Comment #4 from jonny+bg at mail dot hfa3 dot org 2010-05-31 23:46
---
Same as comment 3, hopefully in pre tags this time.
For clarity, a smaller test is:
__inline __attribute__ ((gnu_inline)) void func () { }
int main() { func(); return 0; }
$ g++ foo.cpp
/tmp/cc31L8fw.o: In function `main':
foo.cpp:(.text+0x5): undefined reference to `func()'
collect2: ld returned 1 exit status
Most people who hit this bug are likely using gperf.
$ gperf -N func
. . .
#ifdef __GNUC__
__inline
#if defined __GNUC_STDC_INLINE__ || defined __GNUC_GNU_INLINE__
__attribute__ ((__gnu_inline__))
#endif
#endif
const char * func (str, len)
. . .
$ gperf -N func -L C++ # will and avoid this bug :-) but also renames func to
Perfect_Hash::func :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41194
[Bug middle-end/44356] [4.6 regression] FAIL: gcc.dg/tree-ssa/loadpre6.c
-- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-01 01:27:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44356
[Bug fortran/44354] incorrect output at run time
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2010-06-01 02:09 --- My take on this as I was reading through this thread before I got to comment #13 is that the code has to be illegal. I vote for the error. I think it would be bad practice too introduce this as an extension or for some other reason. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug tree-optimization/39874] [4.4 regression] missing VRP (submission)
--- Comment #4 from sandra at codesourcery dot com 2010-06-01 02:22 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg1.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39874
[Bug middle-end/28685] Multiple comparisons are not simplified
--- Comment #15 from sandra at codesourcery dot com 2010-06-01 02:24 --- Proposed patch for PR 39874/comment #5 posted here: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg1.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685
[Bug fortran/44354] incorrect output at run time
--- Comment #15 from sgk at troutmask dot apl dot washington dot edu 2010-06-01 03:07 --- Subject: Re: incorrect output at run time On Tue, Jun 01, 2010 at 02:09:38AM -, jvdelisle at gcc dot gnu dot org wrote: My take on this as I was reading through this thread before I got to comment #13 is that the code has to be illegal. I vote for the error. I think it would be bad practice too introduce this as an extension or for some other reason. Note that i = 5 print *, (i,i=1,i) end is valid Fortran and gfortran currently gives the expected result. The distinction is the above is an io-implied-do. The original code contains an ac-implied-do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug fortran/44354] incorrect output at run time
--- Comment #16 from jvdelisle at verizon dot net 2010-06-01 03:46 --- Subject: Re: incorrect output at run time On 05/31/2010 08:07 PM, sgk at troutmask dot apl dot washington dot edu wrote: --- Comment #15 from sgk at troutmask dot apl dot washington dot edu 2010-06-01 03:07 --- Subject: Re: incorrect output at run time On Tue, Jun 01, 2010 at 02:09:38AM -, jvdelisle at gcc dot gnu dot org wrote: My take on this as I was reading through this thread before I got to comment #13 is that the code has to be illegal. I vote for the error. I think it would be bad practice too introduce this as an extension or for some other reason. Note that i = 5 print *, (i,i=1,i) end is valid Fortran and gfortran currently gives the expected result. The distinction is the above is an io-implied-do. The original code contains an ac-implied-do. Understood! Jerry -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug c++/44357] New: internal compiler error: in cgraph_decide_inlining_of_small_functions
Compiling DwarfException.cpp fails with this error: DwarfException.cpp:960:1: internal compiler error: in cgraph_decide_inlining_of_small_functions, at ipa-inline.c:1013 but works with gcc version 4.4.4 20100503 (Red Hat 4.4.4-2) (GCC) -- Summary: internal compiler error: in cgraph_decide_inlining_of_small_functions Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vladimir at acm dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44357
[Bug c++/44357] internal compiler error: in cgraph_decide_inlining_of_small_functions
--- Comment #1 from vladimir at acm dot org 2010-06-01 04:18 --- Created an attachment (id=20788) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20788action=view) Pre-processed source that exhibits failure, part 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44357
[Bug c++/44357] internal compiler error: in cgraph_decide_inlining_of_small_functions
--- Comment #2 from vladimir at acm dot org 2010-06-01 04:18 --- Created an attachment (id=20789) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20789action=view) Pre-processed source that exhibits failure, part 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44357
[Bug fortran/44354] incorrect output at run time
--- Comment #17 from pault at gcc dot gnu dot org 2010-06-01 04:31 --- (In reply to comment #13) Due to my confusion over the scope of 'i' and 'I', I posted to c.l.f. As usual Richard Maine pieced through the standard's language. http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/1f88cd2dec855d73# As John Harper did on the above thread, I found: fortcom: Error: pr44354.f90, line 3: It is not permissible to reference the value of an ac-implied-do variable in one of its limit expressions print *,(/(i,i=1,I)/) -^ compilation aborted for pr44354.f90 (code 1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44354
[Bug fortran/44353] rejects legal fortran
--- Comment #1 from pault at gcc dot gnu dot org 2010-06-01 04:51 --- Other compilers produce the expected result, whereas gfortran gives: pr44353.f90:4.19: data (ii(i),i=1,10) /10*1/ ! here the scope of i is the data statement 1 Error: Loop variable 'i' at (1) cannot be INTENT(IN) Removing the error at match.c:981 makes gfortran behave as the other compilers. In addition, I cannot find any such constraint in the standard. Execution of a data-implied-do is the same as a DO and so the scope of the loop variable is local to the data statement. Given all this, I would say confirmed. I will regtest the fix a bit later on. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-01 04:51:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44353
[Bug fortran/44348] ICE in build_function_decl
--- Comment #1 from pault at gcc dot gnu dot org 2010-06-01 05:02 ---
This is rather easily fixed, I suspect:
if (sym-attr.dummy sym-attr.if_source == IFSRC_DECL)
{
...error...
}
in resolve.c should do the job. Just have to find the right place!
Confirmed
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-invalid-code
Last reconfirmed|-00-00 00:00:00 |2010-06-01 05:02:32
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44348
