[Bug other/61979] Why float variable loading twice into the FTU Stack during condition checking ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61979 --- Comment #2 from Srikanth nasika.srikanth1 at gmail dot com --- Created attachment 33225 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33225action=edit In this assemble code line number at 22-25 and after 27-30 both are same instructions repeated for conditional checking. In this assemble code line number at 22-25 and after 27-30 both are same instructions repeated for conditional checking. Architecture Intel® Core™ i3-2350M CPU @ 2.30GHz × 4 Sorry its my mistype *not FTU*,its actually FPU Stack means Floating point unit stack I just patch the above code by removing the repeated code filetestcondition.c .section.rodata .LC2: .stringtrue .LC3: .stringfalse .text .globlmain .typemain, @function main: .LFB0: .cfi_startproc pushl%ebp .cfi_def_cfa_offset 8 .cfi_offset 5, -8 movl%esp, %ebp .cfi_def_cfa_register 5 andl$-16, %esp subl$32, %esp movl.LC0, %eax movl%eax, 28(%esp) flds28(%esp) fldz fucomip%st(1), %st fstp%st(0) jp.L6 je.L7 .L6: movl$.LC2, (%esp) callprintf jmp.L4 .L7: movl$.LC3, (%esp) callprintf .L4: movl$0, %eax leave .cfi_restore 5 .cfi_def_cfa 4, 4 ret .cfi_endproc .LFE0: .sizemain, .-main .section.rodata .align 4 .LC0: .long1094713344 .identGCC: (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1 .section.note.GNU-stack,,@progbits
[Bug other/61979] Why float variable loading twice into the FTU Stack during condition checking ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61979 --- Comment #3 from Srikanth nasika.srikanth1 at gmail dot com --- Comment on attachment 33225 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33225 In this assemble code line number at 22-25 and after 27-30 both are same instructions repeated for conditional checking. filetestcondition.c .section.rodata .LC2: .string true .LC3: .string false .text .globl main .type main, @function main: .LFB0: .cfi_startproc pushl %ebp .cfi_def_cfa_offset 8 .cfi_offset 5, -8 movl%esp, %ebp .cfi_def_cfa_register 5 andl$-16, %esp subl$32, %esp movl.LC0, %eax movl%eax, 28(%esp) flds28(%esp) fldz fucomip %st(1), %st fstp%st(0) jp .L6 flds28(%esp) fldz fucomip%st(1), %st fstp%st(0) je .L7 .L6: movl$.LC2, (%esp) callprintf jmp .L4 .L7: movl$.LC3, (%esp) callprintf .L4: movl$0, %eax leave .cfi_restore 5 .cfi_def_cfa 4, 4 ret .cfi_endproc .LFE0: .size main, .-main .section.rodata .align 4 .LC0: .long 1094713344 .ident GCC: (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1 .section.note.GNU-stack,,@progbits
[Bug c++/61993] constexpr static member function is not constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61993 --- Comment #2 from steveren q@rsn-tech.co.uk --- Ah, it is a dupe; sorry, I missed that one.
[Bug other/61979] Why float variable loading twice into the FPU Stack during condition checking ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61979 --- Comment #4 from Srikanth nasika.srikanth1 at gmail dot com --- In the Above comment-3 assembly code with black color letter are the repeated code i.e storing the float variable twice in FPU stack during conditional checking for parity flag and zero flag. I just patch that one by removing repeated code ,after checking the parity flag i just check the zero flag with out loading it again into the FPU Stack and again compare with zero .
[Bug other/61979] Why float variable loading twice into the FPU Stack during condition checking ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61979 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- Where is the testcase, this is only the assembly output.
[Bug other/61979] Why float variable loading twice into the FPU Stack during condition checking ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61979
--- Comment #6 from Srikanth nasika.srikanth1 at gmail dot com ---
int main()
{
float m=12
m?printf(true):printf(false);
m=0;
m?printf(true):printf(false);
}
and above is the assemble code generated from the source file .. when i seeing
the assemble code i just recognize that float variable was loading twice during
the conditional checking that's what my doubt ? please tell me why after
comparison of parity flag for NAN or not,directly we can check for zero flag
for zero or not.But the generated assemble code in #comment 3 ,after comparison
of parity flag it again loading the same variable into the FPU stack and again
comparing with zero and checking for zero flag and goes to true or false
statment why?
[Bug fortran/61960] internal compiler error: in gfc_conv_component_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61960 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-02 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Reduced test module data_func_mod implicit none integer, parameter :: sp = 4 type :: data_type real(kind=sp), pointer, dimension(:, :) :: data = null() integer :: nr_rows = 0, nr_cols = 0 end type data_type contains function get_row(this, i) result(row) implicit none type(data_type), intent(in) :: this integer, intent(in) :: i real(kind=sp), dimension(this%nr_cols) :: row row = this%data(:, i) end function get_row subroutine print_matrix(m) implicit none class(data_type), intent(in) :: m integer :: i character(len=20) :: fmt_str write (unit=6, fmt=fmt_str) get_row(m, 1) end subroutine print_matrix end module data_func_mod Before revision r182107 (2011-12-08) compiling the test gave the error pr61960_red.f90:24.48: write (unit=6, fmt=fmt_str) get_row(m, 1) 1 Error: Type mismatch in argument 'this' at (1); passed CLASS(data_type) to TYPE(data_type) At revision r183001 (2012-01-09) the original and the reduced tests compile up to revision r183968 (2012-02-03). From revision r184278 (2012-02-15) up to trunk the compilation gives an ICE in trans-expr.c.
[Bug other/61979] Why float variable loading twice into the FPU Stack during condition checking ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61979 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #7 from Marc Glisse glisse at gcc dot gnu.org --- Your testcase is missing a ';', a #include and a return. You don't say how you compiled, but clearly you didn't pass any optimization flag (-O2 for instance), so you shouldn't expect optimized code.
[Bug fortran/61952] ICE allocattion of array of type of type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61952 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-02 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed from 4.5 up to trunk (4.10, r213515).
[Bug sanitizer/61995] New: gcc 4.9.1 fails to compile with error in libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61995 Bug ID: 61995 Summary: gcc 4.9.1 fails to compile with error in libsanitizer Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: smith_winston_6079 at hotmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org gcc 4.9.1 fails to compile with an error when getting to compile libsanizer. Here's my transcript: $ ../gcc-4.9.1/configure --prefix=/usr/ --with-local-prefix=/usr/local/ --with-native-system-header-dir=/usr/include/ --disable-libada --enable-libssp --enable-libquadmath --enable-nls --with-included-gettext --enable-shared --enable-threads --disable-bootstrap --enable-languages=c,c++,fortran,go,objc,obj-c++ --enable-werror --enable-gather-detailed-mem-stats --disable-multilib checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /bin/sed checking for gawk... gawk checking for libatomic support... yes checking for libcilkrts support... yes checking for libitm support... yes checking for libsanitizer support... yes checking for libvtv support... yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking whether g++ accepts -static-libstdc++ -static-libgcc... no checking for gnatbind... gnatbind checking for gnatmake... gnatmake checking whether compiler driver understands Ada... yes checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for objdir... .libs checking for version 0.10 of ISL... no checking for version 0.11 of ISL... no checking for version 0.12 of ISL... no The following languages will be built: c,c++,fortran,go,lto,objc,obj-c++ checking for default BUILD_CONFIG... checking for --enable-vtable-verify... no checking for bison... bison -y checking for bison... bison checking for gm4... no checking for gnum4... no checking for m4... m4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... expect checking for runtest... runtest checking for ar... ar checking for as... as checking for dlltool... no checking for ld... ld checking for lipo... no checking for nm... nm checking for ranlib... ranlib checking for strip... strip checking for windres... no checking for windmc... no checking for objcopy... objcopy checking for objdump... objdump checking for readelf... readelf checking for cc... cc checking for c++... c++ checking for gcc... gcc checking for gcj... no checking for gfortran... gfortran checking for gccgo... no checking for ar... no checking for ar... ar checking for as... no checking for as... as checking for dlltool... no checking for dlltool... no checking for ld... no checking for ld... ld checking for lipo... no checking for lipo... no checking for nm... no checking for nm... nm checking for objdump... no checking for objdump... objdump checking for ranlib... no checking for ranlib... ranlib checking for readelf... no checking for readelf... readelf checking for strip... no checking for strip... strip checking for windres... no checking for windres... no checking for windmc... no checking for windmc... no checking where to find the target ar... host tool checking where to find the target as... host tool checking where to find the target cc... just compiled checking where to find the target c++... just compiled checking where to find the target c++ for libstdc++... just compiled checking where to find the target dlltool... host tool checking where to find the target gcc... just compiled checking where to find the target gcj... host tool checking where to find the target gfortran... just compiled checking where to find the target gccgo... just compiled checking where to find the target ld... host tool checking where to find the target lipo... host tool checking where to find the target nm... host tool checking where to find the target objdump... host tool checking where to find the target ranlib... host tool checking where to find the target readelf... host tool checking where to
[Bug sanitizer/61995] gcc 4.9.1 fails to compile with error in libsanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61995 --- Comment #1 from Winston Smith smith_winston_6079 at hotmail dot com --- I meant to say that configure --help also does not show this option.
[Bug target/61996] New: [SH] -musermode conflicts with -matomic-model=soft-imask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61996 Bug ID: 61996 Summary: [SH] -musermode conflicts with -matomic-model=soft-imask Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target: sh*-*-* Originally reported log: checking for suffix of object files... configure: error: in `/data/fedora/cross-gcc/gcc-4.9.1-20140717/sh-linux-gnu/sh-linux-gnu/libgcc': configure: error: cannot compute suffix of object files: cannot compile [in config.log] conftest.c:1:0: error: cannot use atomic model soft-imask in user mode It seems that when building for SH1/SH2/SH2A sh-linux, the -musermode option is set by default and then conflicts with the default -matomic-model=soft-imask setting. Proposed fix: - musermode should have no effect on SH targets that don't have user/privileged modes (SH1, SH2, SH2A). - mno-usermode should be added to allow disabling user mode restrictions when it is enabled by default (i.e. in sh-*-linux case).
[Bug fortran/61928] a fortran90 program compiles on hopper at NERSC but not under gfortran 4.9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61928 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-08-02 CC||kargl at troutmask dot apl.washing ||ton.edu Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Reduced test program Z0linpack ! with LINPACK's dgedi and dgefa, and SLATEC's idamax implicit none integer( kind = 4 )::n integer( kind = 4 )::info,lda integer( kind = 4 ),allocatable:: IPVT(:) integer( kind = 4 ),parameter::ns=10,job=10 doubleprecision,dimension(:,:),allocatable::A call dgefa ( A, lda, n, ipvt, info ) contains subroutine dgefa ( a, lda, n, ipvt, info ) implicit none integer ( kind = 4 ) lda integer ( kind = 4 ) n real ( kind = 8 ) a(lda,n) integer ( kind = 4 ) info integer ( kind = 4 ) ipvt(n) integer ( kind = 4 ) idamax integer ( kind = 4 ) k integer ( kind = 4 ) l k = 1 l = idamax ( n-k+1, a(k,k), 1 ) + k - 1 return end function idamax ( n, dx, incx ) implicit none real ( kind = 8 ) dx(*) integer ( kind = 4 ) idamax integer ( kind = 4 ) incx integer ( kind = 4 ) n idamax = 0 return end end program Z0linpack [Book15] f90/bug% gfc pr61928_red.f90 Undefined symbols for architecture x86_64: _idamax_, referenced from: _dgefa.2338 in cc23XSKJ.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status However if I comment the line integer ( kind = 4 ) idamax in the subroutine dgefa, the code compiles and links without error. AFAIK the subroutine dgefa and the function idamax are not designed to be internal procedures. It seems that with the above line gfortran assumes that idamax is an external function and not the internal one; however I don't know where to find it in the standard. I suspect that this PR should be closed as invalid, but I let someone else to make the call! Note that compiling the code with gfortran 4.5 gives a lot of errors, starting with pr61928_red.f90:29.2: end 1 Error: END SUBROUTINE statement expected at (1) pr61928_red.f90:31: function idamax ( n, dx, incx ) 1 Error: Unclassifiable statement at (1) ...
[Bug target/61997] New: cc1plus ICE with aarch64 target using PCH and builtin functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61997 Bug ID: 61997 Summary: cc1plus ICE with aarch64 target using PCH and builtin functions Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rmorell at nvidia dot com Created attachment 33226 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33226action=edit Test case This reproduces with at least GCC 4.8.2, 4.8.3, and SVN r213491. I believe it's present in every version that supports the aarch64 target. I have been using GCC configured with: configure --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --target=aarch64-unknown-linux-gnu --enable-languages=c,c++ --enable-threads=posix --enable-shared --disable-libsanitizer --disable-gnu-indirect-function --disable-gnu-unique-object --with-sysroot=/gcc-debug/Linux-aarch64-sysroot --disable-multilib The simplest reproduction case that I've found is to precompile a header with exactle one line in it, call it precomp.h: #define CEILF(f) ceilf(f) Compile the PCH with: aarch64-unknown-linux-gnu-gcc -nostdinc -march=armv8-a -fPIC -O2 -ftree-vectorize -x c++-header -c precomp.h -o precomp.h.ghc Then build the attached longish creduce'd test case with: aarch64-unknown-linux-gnu-gcc -nostdinc -march=armv8-a -fPIC -O2 -ftree-vectorize -x c++ -include precomp.h -Winvalid-pch -c test.c It fails with SEGV: test.c: In function ‘void x127()’: test.c:141:1: internal compiler error: Segmentation fault x127 () ^ 0x899d958 crash_signal /gcc-debug/gcc-svn/gcc/toplev.c:337 0x81bbd62 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) /gcc-debug/gcc-svn/gcc/tree.h:2841 0x87208ca gimple_build_call_1 /gcc-debug/gcc-svn/gcc/gimple.c:216 0x872093d gimple_build_call_vec(tree_node*, vectree_node*, va_heap, vl_ptr) /gcc-debug/gcc-svn/gcc/gimple.c:230 0x8bd85e0 vectorizable_call /gcc-debug/gcc-svn/gcc/tree-vect-stmts.c:2470 0x8be7b1f vect_transform_stmt(gimple_statement_base*, gimple_stmt_iterator*, bool*, _slp_tree*, _slp_instance*) /gcc-debug/gcc-svn/gcc/tree-vect-stmts.c:7237 0x8bfb143 vect_transform_loop(_loop_vec_info*) /gcc-debug/gcc-svn/gcc/tree-vect-loop.c:6079 0x8c0e4f1 vectorize_loops() /gcc-debug/gcc-svn/gcc/tree-vectorizer.c:478 0x8b1c75c execute /gcc-debug/gcc-svn/gcc/tree-ssa-loop.c:232 It looks like the reason for the failure is that the global table aarch64_builtin_decls in aarch64-builtins.c isn't relocated when loading the PCH. All of the nodes that it points to are freed, and the memory may get reused (or poisoned, if that's enabled). The table is properly annotated with the GTY macro, but aarch64-builtins.c isn't in GTFILES so it's not processed by the type generator. If I manually add aarch64-builtins.c to target_gtfiles (and include the resulting gt-aarch64-builtins.h at the bottom of the C file) then this problem goes away.
[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842 --- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Oleg Endo from comment #3) (In reply to Jorn Wolfgang Rennecke from comment #2) For the -mrelax breakage, also see: http://sourceware.org/bugzilla/show_bug.cgi?id=3298 Fixes for -mrelax have been posted by Renesas in 2009: https://sourceware.org/bugzilla/show_bug.cgi?id=10373 https://sourceware.org/bugzilla/show_bug.cgi?id=10378 These two issues have been now been fixed in binutils.
[Bug fortran/61910] undefined computation in trans-expr.c gfc_conv_cst_int_power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61910 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-08-02 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Analyzing with sanitized gfortran the following line ... I cannot reproduce it. Which options are you using? And does the message depend on the value of i?
[Bug fortran/61928] a fortran90 program compiles on hopper at NERSC but not under gfortran 4.9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61928 --- Comment #6 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- My thinking, right or wrong, is that the code is invalid because idamax is defined as an integer which conflicts with the subroutine name. Ifort gives the exact same error. (Ifort also insists that the end statements for the function and subroutine state end function and end subroutine but that is a separate issue.)
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #22 from Eric Martin ericmark26 at gmail dot com --- Was your gcc.rb git post intended as a replacement file for gcc.rb, or as a patch for it? Either way, using it for either purpose has been unsuccessful for me. I am getting: /usr/bin/patch: malformed patch at line 13: version_as_macro (void) --- Comment #23 from Eric Martin ericmark26 at gmail dot com --- (In reply to Eric Martin from comment #22) Was your gcc.rb git post intended as a replacement file for gcc.rb, or as a patch for it? Either way, using it for either purpose has been unsuccessful for me. I am getting: /usr/bin/patch: malformed patch at line 13: version_as_macro (void) However, your patch do ... end block before the line you suggested allowed it to compile when setting autolibs=4 and compiling --with-gcc=clang
[Bug other/61979] Why float variable loading twice into the FPU Stack during condition checking ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61979
--- Comment #8 from Srikanth nasika.srikanth1 at gmail dot com ---
#includestdio.h
int main()
{
float m=12;
m?printf(true):printf(false);
m=0;
m?printf(true):printf(false);
return 0;
}
complied : gcc -S testcase.c -o testcase.s
[Bug ipa/61998] New: [4.10 Regression] ICE: Segmentation fault with -Wsuggest-final-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61998 Bug ID: 61998 Summary: [4.10 Regression] ICE: Segmentation fault with -Wsuggest-final-types Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: hubicka at gcc dot gnu.org markus@x4 ~ % touch foo.ii markus@x4 ~ % g++ -Wsuggest-final-types -O2 foo.ii foo.ii:1:0: internal compiler error: Segmentation fault 0xb9445f crash_signal ../../gcc/gcc/toplev.c:337 0x9fcab9 ipa_devirt ../../gcc/gcc/ipa-devirt.c:3102 0x9fcab9 execute ../../gcc/gcc/ipa-devirt.c:3372 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Also both -Wsuggest-final-types -Wsuggest-final-methods should probably only be enabled for C++11 or higher, because C++98 doesn't support the final keyword.
[Bug fortran/61928] a fortran90 program compiles on hopper at NERSC but not under gfortran 4.9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61928 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #7 from Harald Anlauf anlauf at gmx dot de --- (In reply to Jerry DeLisle from comment #6) My thinking, right or wrong, is that the code is invalid because idamax is defined as an integer which conflicts with the subroutine name. ^^ internal procedure Ifort gives the exact same error. (Ifort also insists that the end statements for the function and subroutine state end function and end subroutine but that is a separate issue.) Also NAG agrees with you. And NAG is almost always right ;-) I tend do believe that F2008 section 12.2.2 applies here: - The declaration in subroutine dgefa makes it an *external* procedure, - The subprogram in the scope of main makes it a *internal* procedure. Note that: ... Internal subprograms are the same as external subprograms except that the name of the internal procedure is not a global identifier, an internal subprogram shall not contain an ENTRY statement, and the internal subprogram has access to host entities by host association. So gfortran, Ifort and NAG are right and the original code is invalid.
[Bug fortran/61999] New: `gfc_simplify_dot_product` causes ICE for constant arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61999 Bug ID: 61999 Summary: `gfc_simplify_dot_product` causes ICE for constant arguments Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: latlon90180+gcc_bugzilla at gmail dot com Following code leads `gcc-mp-4.8 (MacPorts gcc48 4.8.2_2) 4.8.2` and `GNU Fortran (MacPorts gcc47 4.7.3_5) 4.7.3` to ICE. ```fortran program main use, intrinsic:: iso_fortran_env, only: output_unit implicit none write(output_unit, *) dot_product([1, 2], [2.0, 3.0]) stop end program main ``` ``` f951: internal compiler error: in gfc_simplify_dot_product, at fortran/simplify.c:1886 f951: internal compiler error: Abort trap: 6 gfortran-mp-4.8: internal compiler error: Abort trap: 6 (program f951) Abort trap: 6 ```
[Bug target/61997] cc1plus ICE with aarch64 target using PCH and builtin functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61997 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||aarch64*-*-* --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Also happens with a aarch64-elf gcc.
[Bug target/61997] cc1plus ICE with aarch64 target using PCH and builtin functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61997 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-02 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Confirmed.
[Bug target/61997] cc1plus ICE with aarch64 target using PCH and builtin functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61997 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Robert Morell from comment #0) If I manually add aarch64-builtins.c to target_gtfiles (and include the resulting gt-aarch64-builtins.h at the bottom of the C file) then this problem goes away. That is the correct fix. I am testing this fix then and will be applying to the trunk as obvious after I test it.
[Bug c++/15339] [DR217] Adding default arguments to function templates in redeclarations should be forbidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15339 --- Comment #16 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Sat Aug 2 19:41:32 2014 New Revision: 213519 URL: https://gcc.gnu.org/viewcvs?rev=213519root=gccview=rev Log: /cp 2014-08-02 Paolo Carlini paolo.carl...@oracle.com PR c++/15339 * decl.c (check_redeclaration_no_default_args): New. (duplicate_decls): Use it, handle default arguments in redeclarations of function templates. /testsuite 2014-08-02 Paolo Carlini paolo.carl...@oracle.com PR c++/15339 * g++.dg/other/default9.C: New. * g++.dg/other/default10.C: Likewise. * g++.dg/other/default3.C: Remove xfail. Added: trunk/gcc/testsuite/g++.dg/other/default10.C trunk/gcc/testsuite/g++.dg/other/default9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/other/default3.C
[Bug c++/15339] [DR217] Adding default arguments to function templates in redeclarations should be forbidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15339 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #17 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed.
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #18 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Created attachment 33227 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33227action=edit A preliminary patch This patch is preliminary for proof of principle. If the idea is acceptable, then configuration magic is required to ensure the locale.h is available, and if not, default to '.'.
[Bug c++/15339] [DR217] Adding default arguments to function templates in redeclarations should be forbidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15339 --- Comment #18 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Sat Aug 2 21:38:34 2014 New Revision: 213520 URL: https://gcc.gnu.org/viewcvs?rev=213520root=gccview=rev Log: 2014-08-02 Paolo Carlini paolo.carl...@oracle.com PR c++/15339 * testsuite/26_numerics/headers/complex/synopsis.cc: Fix. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/26_numerics/headers/complex/synopsis.cc
[Bug fortran/61999] [4.8/4.9/4.10 Regression] `gfc_simplify_dot_product` causes ICE for constant arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61999 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-02 Known to work||4.4.7 Summary|`gfc_simplify_dot_product` |[4.8/4.9/4.10 Regression] |causes ICE for constant |`gfc_simplify_dot_product` |arguments |causes ICE for constant ||arguments Ever confirmed|0 |1 Known to fail||4.10.0, 4.5.4, 4.6.4, ||4.7.4, 4.8.3, 4.9.1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- The test compiles and gives 8.0 at run time with gfortran 4.4.7.
[Bug fortran/62000] New: Program hangs on print *, func() statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62000 Bug ID: 62000 Summary: Program hangs on print *, func() statement. Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jannis at teunissen dot net Code example: --- program my_test use mpi implicit none integer :: ierr real:: rr call MPI_init(ierr) call set_real(rr) print *, rr print *, get_real() call MPI_finalize(ierr) contains real function get_real() print *, FUNC get_real = 1.0 end function get_real subroutine set_real(arg) real, intent(out) :: arg print *, SUB arg = 1.0 end subroutine set_real end program my_test --- Compilation: mpif90 (no flags) Result: $ ./a.out SUB 1. ** program hangs indefinitely ** Same result with MPICH instead of OpenMPI (see below). Without MPI, the problem goes away. If print *, get_real() is replaced by: rr = get_real() print *, rr there is again no problem. Open MPI: 1.6.5 GNU Fortran (Debian 4.9.1-1) 4.9.1 Linux debian 3.13-1-amd64 #1 SMP Debian 3.13.10-1 (2014-04-15) x86_64 GNU/Linux
[Bug fortran/62000] Program hangs on print *, func() statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62000 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- You are using Mac OSX and an invalid recursive I/O, see pr30617. *** This bug has been marked as a duplicate of bug 30617 ***
[Bug libfortran/30617] Implement a run time diagnostic for invalid recursive I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||jannis at teunissen dot net --- Comment #38 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 62000 has been marked as a duplicate of this bug. ***
[Bug fortran/62000] Program hangs on print *, func() statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62000 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- You are using Mac OSX and an invalid recursive I/O, see pr30617. I did not look at the end of the report. So apparently recursive I/O hangs also on Linux debian and MPI(?). Without the MPI stuff the code hangs on darwin, but not on gcc version 4.6.3 20120306 (Red Hat 4.6.3-2).
