[Bug fortran/68433] Wrong code with INTERFACE, INTRINSIC, and optional arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68433 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-19 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Present from 4.8 up to trunk (6.0).
[Bug fortran/68433] New: Wrong code with INTERFACE, INTRINSIC, and optional arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68433
Bug ID: 68433
Summary: Wrong code with INTERFACE, INTRINSIC, and optional
arguments
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: dominiq at lps dot ens.fr
Target Milestone: ---
While investigating pr46846, I found that the following code
program ainttest
implicit none
intrinsic aint
intrinsic index
intrinsic len
intrinsic nint
real r
character c, string2
character(7) string1
integer i
r = 3.14
c = 'A'
string2 = 'n'
string1 = 'string1'
i = 13
call rsub('aint',aint,r)
call rsubi('nint',nint,r)
call char2isub('index',index,string1,string2)
call charstarisub('len',len,string1)
end program ainttest
subroutine rsub(label,fun,x)
implicit none
character(*) label
interface
function fun(x,k)
implicit none
integer, intent(in), optional :: k
real, intent(in) :: x
real fun
end function fun
end interface
real x
write(*,*) label//'(',x,') = ',fun(x,k=8)
print *, "expected:", aint(x,kind=8)
end subroutine rsub
subroutine rsubi(label,fun,x)
implicit none
character(*) label
interface
function fun(x,k)
implicit none
integer, intent(in), optional :: k
real, intent(in) :: x
integer fun
end function fun
end interface
real x
write(*,*) label//'(',x,') = ',"'",fun(x,k=2),"'"
print *, "expected:","'",nint(x,kind=2),"'"
end subroutine rsubi
subroutine char2isub(label,fun,x,y)
implicit none
character(*) label,x,y
interface
function fun(x,y,l,k)
implicit none
logical, intent(in), optional :: l
integer, intent(in), optional :: k
character(*), intent(in) :: x,y
integer fun
end function fun
end interface
write(*,*) label//'(',x,',',y,') = ',fun(x,y)
print *, "expected:", index(x,y)
end subroutine char2isub
subroutine charstarisub(label,fun,x)
implicit none
character(*) label,x
write(*,*) label//'(',x,') = ',fun(x)
print *, "expected:", len(x)
end subroutine charstarisub
while silencing the spurious warnings, generates a wrong code, the output
being:
aint( 3.1410 ) =3.
expected: 3.
nint( 3.1410 ) = ' 3 '
expected:' 3 '
index(string1,n) =1
expected: 5
len(string1) =0
expected: 7
Note that I am not 100% sure that the above code is valid.
[Bug middle-end/68393] internal compiler error: in convert_move, at expr.c:286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68393 --- Comment #5 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Thu Nov 19 08:17:21 2015 New Revision: 230590 URL: https://gcc.gnu.org/viewcvs?rev=230590&root=gcc&view=rev Log: PR 68393: Handle SUBREG_PROMOTED_VAR_P in expand_direct_optab_fn Do the usual dance when assigning to SUBREG_PROMOTED_VAR_P destinations: first convert to the outer mode, then extend to the inner mode. Tested that it fixes the powerpc64le-linux-gnu breakage. Also tested on x86_64-linux-gnu and powerpc64-linux-gnu. gcc/ PR bootstrap/68393 * internal-fn.c (expand_direct_optab_fn): Handle SUBREG_PROMOTED_VAR_P destinations. Modified: trunk/gcc/ChangeLog trunk/gcc/internal-fn.c
[Bug fortran/64522] [4.9 Regression] Free-form source code: -Wline-truncation is no longer enabled by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64522 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING Known to work||5.2.0, 6.0 Summary|[4.9/5/6 Regression]|[4.9 Regression] Free-form |Free-form source code: |source code: |-Wline-truncation is no |-Wline-truncation is no |longer enabled by default |longer enabled by default Known to fail||4.9.3 --- Comment #6 from Dominique d'Humieres --- Fixed on 5.2 and trunk (6.0). IMO backporting r219424 to 4.9.4 does not worth the work. Unless someone objects (and do the work), I'll close this PR as FIXED.
[Bug preprocessor/60736] [4.9/5/6 Regression] Crash in preprocessor including stdc-predef.h when it does not exist on glibc-based systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736 --- Comment #15 from Jakub Jelinek --- Author: jakub Date: Thu Nov 19 08:27:12 2015 New Revision: 230591 URL: https://gcc.gnu.org/viewcvs?rev=230591&root=gcc&view=rev Log: PR preprocessor/60736 * include/cpplib.h (cpp_errno_filename): New prototype. * errors.c (cpp_errno): Don't handle msgid "" specially, use _(msgid) instead of msgid as argument to cpp_error. (cpp_errno_filename): New function. * files.c (read_file_guts): Use cpp_errno_filename instead of cpp_errno. (open_file_failed): Likewise. Use file->name if file->path is NULL in diagnostics. Modified: trunk/libcpp/ChangeLog trunk/libcpp/errors.c trunk/libcpp/files.c trunk/libcpp/include/cpplib.h
[Bug preprocessor/60736] [4.9/5/6 Regression] Crash in preprocessor including stdc-predef.h when it does not exist on glibc-based systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736 --- Comment #16 from Jakub Jelinek --- Author: jakub Date: Thu Nov 19 08:28:43 2015 New Revision: 230592 URL: https://gcc.gnu.org/viewcvs?rev=230592&root=gcc&view=rev Log: PR preprocessor/60736 * include/cpplib.h (cpp_errno_filename): New prototype. * errors.c (cpp_errno): Don't handle msgid "" specially, use _(msgid) instead of msgid as argument to cpp_error. (cpp_errno_filename): New function. * files.c (read_file_guts): Use cpp_errno_filename instead of cpp_errno. (open_file_failed): Likewise. Use file->name if file->path is NULL in diagnostics. Modified: branches/gcc-5-branch/libcpp/ChangeLog branches/gcc-5-branch/libcpp/errors.c branches/gcc-5-branch/libcpp/files.c branches/gcc-5-branch/libcpp/include/cpplib.h
[Bug target/67770] [4.9/5/6 Regression] i386: -fshrink-wrap can interact badly with trampolines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67770 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Thu Nov 19 08:30:19 2015 New Revision: 230593 URL: https://gcc.gnu.org/viewcvs?rev=230593&root=gcc&view=rev Log: PR target/67770 * config/i386/i386.md (simple_return): Disable if ix86_static_chain_on_stack is true. * gcc.target/i386/pr67770.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr67770.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug c++/68383] Demangler stack overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68383 --- Comment #8 from fiesh at zefix dot tv --- Would it be helpful it I tried to create a test case for 5.2.0? Or anything else I can provide?
[Bug fortran/66707] Endless compilation on wrong usage of common
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66707 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #2 from Dominique d'Humieres --- > Confirmed with 4.9.3 and 5.2. This seems to have been fixed on trunk between > revision r226476 (2015-08-02, endless compilation) and r227016 (2015-08-19, > tests compiled in a fraction of second). Can someone confirms that the tests compile on recent trunk (post r227016)? A finer range would be nice too!
[Bug rtl-optimization/67609] [5 Regression] Generates wrong code for SSE2 _mm_load_pd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67609 Richard Henderson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #38 from Richard Henderson --- Fixed for 5.3.
[Bug target/67770] [4.9/5/6 Regression] i386: -fshrink-wrap can interact badly with trampolines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67770 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Thu Nov 19 08:47:24 2015 New Revision: 230595 URL: https://gcc.gnu.org/viewcvs?rev=230595&root=gcc&view=rev Log: PR target/67770 * config/i386/i386.md (simple_return): Disable if ix86_static_chain_on_stack is true. * gcc.target/i386/pr67770.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr67770.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/i386/i386.md branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 --- Comment #39 from Richard Biener --- Author: rguenth Date: Thu Nov 19 08:47:16 2015 New Revision: 230594 URL: https://gcc.gnu.org/viewcvs?rev=230594&root=gcc&view=rev Log: 2015-11-19 Richard Biener PR middle-end/68117 * tree-ssa.c (delete_tree_ssa): Revert removal of call to redirect_edge_var_map_destroy. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa.c
[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68432 Richard Biener changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Target Milestone|--- |6.0
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #40 from Richard Biener --- Fixed.
[Bug rtl-optimization/68376] [4.9/5/6 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68376 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Thu Nov 19 08:49:59 2015 New Revision: 230596 URL: https://gcc.gnu.org/viewcvs?rev=230596&root=gcc&view=rev Log: PR rtl-optimization/68376 * ifcvt.c (noce_try_abs): Disable one_cmpl optimization if encountering x <= 0 ? ~x : x or x > 0 ? ~x : x. * gcc.c-torture/execute/pr68376-1.c: New test. * gcc.c-torture/execute/pr68376-2.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr68376-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr68376-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/ifcvt.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/68376] [4.9/5/6 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68376 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Thu Nov 19 08:53:52 2015 New Revision: 230597 URL: https://gcc.gnu.org/viewcvs?rev=230597&root=gcc&view=rev Log: PR rtl-optimization/68376 * ifcvt.c (noce_try_abs): Disable one_cmpl optimization if encountering x <= 0 ? ~x : x or x > 0 ? ~x : x. * gcc.c-torture/execute/pr68376-1.c: New test. * gcc.c-torture/execute/pr68376-2.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/pr68376-1.c branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/pr68376-2.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/ifcvt.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug c++/68383] Demangler stack overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68383 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-19 Ever confirmed|0 |1 --- Comment #9 from Markus Trippelsdorf --- (In reply to fiesh from comment #8) > Would it be helpful it I tried to create a test case for 5.2.0? Or anything > else I can provide? The reduced testcase works with all gcc versions.
[Bug tree-optimization/68341] [6 Regression] FAIL: gcc.dg/graphite/interchange-{1,11,13}.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68341 --- Comment #3 from vries at gcc dot gnu.org --- FTR, related comment at https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01792.html
[Bug other/66827] [6 Regression] left shifts of negative value warnings due to C++14 switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66827 --- Comment #6 from Paolo Bonzini --- If you really want to fix it, (-(1 << 19)) is the best. The real fix would be to lobby the C/C++ committees so that left shift of a negative value is unspecified behavior rather than undefined.
[Bug tree-optimization/68198] [6 Regression]Excessive code size, compile time and memory usage bloat due to FSM threading in 453.povray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68198 --- Comment #11 from ktkachov at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #10) > Should be fixed on the trunk now. I went from some absurd time down to less > than a second for the critical code in 453.povray. Yep, I can confirm that as well. Thanks!
[Bug middle-end/68279] ICE: in create_pw_aff_from_tree, at graphite-sese-to-poly.c:836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68279 Jana Saout changed: What|Removed |Added CC||jana at saout dot de --- Comment #3 from Jana Saout --- Created attachment 36769 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36769&action=edit Reduced testcase from liborc Hi, I am probably hitting the same bug when trying to compile liborc. Here's a reduced testcase that still triggers the ICE for me: gcc -O2 -ftree-loop-linear -c create_pw_aff_from_tree-ice.c -o create_pw_aff_from_tree-ice.o create_pw_aff_from_tree-ice.c: In function 'orc_compiler_sse_init': create_pw_aff_from_tree-ice.c:11:6: internal compiler error: in create_pw_aff_from_tree, at graphite-ssse-to-poly.c:713 void orc_compiler_sse_init (OrcCompiler *compiler) ^ Please submit a full bug report, with preprocessed source if appropriate
[Bug c++/68427] GCC (G++) flunks legal ANSI-C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68427 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-11-19 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- The file is very weirdly archived, can you post just the preprocessed source file?
[Bug fortran/68237] ICE on invalid with submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68237
--- Comment #10 from Paul Thomas ---
(In reply to Paul Thomas from comment #9)
> I'll take a look at Steve's proposed patch tonight. In the meantime, I have
> taken the PR.
>
> Cheers
>
> Paul
Steve's patch is good... obvious, even :-)
Here is a dejagnuified version of the testcase:
! { dg-do compile }
!
! Test the fix for PR68237 in which 'foo' caused a seg fault rather than an
error.
!
! Contributed by Martin Reinecke
!
module m1
interface
module subroutine bar
end subroutine
end interface
end module m1
submodule (m1) m2
contains
module procedure foo ! { dg-error "must be in a generic module interface" }
end procedure ! { dg-error "Expecting END SUBMODULE statement" }
end submodule
I'll try to find the time to commit this afternoon; otherwise it will be next
week.
Paul
[Bug c/68431] Regression in GCC-6.0.0's optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68431 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- This got changed in r225108.
[Bug fortran/68243] QOI: no warning about unused entities in submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68243 --- Comment #5 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #1) > Confirmed. Isn't this testcase a demonstration that unused3 and unused4 can be used outside of m2? module m1 implicit none private interface module subroutine s1 end subroutine end interface public s1 integer unused1 contains subroutine unused2 end subroutine end module submodule (m1) m2 implicit none integer :: unused3 = 9 contains subroutine unused4 unused3 = 99 end subroutine end submodule submodule (m1:m2) m3 implicit none contains module procedure s1 print *, unused3 call unused4 print *, unused3 end procedure end submodule use m1 call s1 end Cheers Paul
[Bug c++/68430] std::is_constructible::value == true for unconstructable type T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68430 --- Comment #1 from Jonathan Wakely --- The standard isn't clear about what should happen here, there will be an issue opened about it.
[Bug c++/68427] GCC (G++) flunks legal ANSI-C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68427 Jonathan Wakely changed: What|Removed |Added Severity|major |normal
[Bug c/68431] Regression in GCC-6.0.0's optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68431 --- Comment #2 from Marek Polacek --- In extract_range_from_binary_expr_1 we have /* When vr0.max < 0, vr1.min != 0 and value ranges for dividend and divisor are available. */ if (vr1.type == VR_RANGE && !symbolic_range_p (&vr0) && !symbolic_range_p (&vr1) && !compare_values (vr1.min, zero)) max = int_const_binop (code, vr0.max, vr1.min); else max = zero; but that looks weird: the comment says "vr1.min != 0" but "&& !compare_values (vr1.min, zero)" ensures that vr1.min is zero.
[Bug tree-optimization/68431] [6 Regression] Regression in GCC-6.0.0's optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68431 Marek Polacek changed: What|Removed |Added Component|c |tree-optimization Target Milestone|--- |6.0 Summary|Regression in GCC-6.0.0's |[6 Regression] Regression |optimizer |in GCC-6.0.0's optimizer
[Bug tree-optimization/68431] [6 Regression] Regression in GCC-6.0.0's optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68431 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-11-19 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Marek Polacek --- So should be trivial to fix, if I understood this right.
[Bug fortran/66762] ICE when compiling gfortran.dg/submodule_[16].f90 with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66762 --- Comment #10 from Paul Thomas --- Created attachment 36770 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36770&action=edit Fix for the PR The attached patch fixes the problem but is, as yet, not regtested. Cheers Paul
[Bug middle-end/68393] internal compiler error: in convert_move, at expr.c:286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68393 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from rsandifo at gcc dot gnu.org --- Patch applied.
[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68432 --- Comment #1 from rsandifo at gcc dot gnu.org --- Just to check: is this x86_64-linux-gnu?
[Bug lto/61313] configure incorrectly strips $target_alias from PLUGIN_LD_SUFFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61313 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Version|unknown |4.9.3 Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- Let's just revert part of the change then, no big deal.
[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68432 Joost VandeVondele changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #2 from Joost VandeVondele --- (In reply to rsand...@gcc.gnu.org from comment #1) > Just to check: is this x86_64-linux-gnu? yes it is.x86_64-pc-linux-gnu
[Bug rtl-optimization/68432] [6 Regression] internal compiler error: in expand_insn, at optabs.c:6947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68432 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-11-19 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from rsandifo at gcc dot gnu.org --- Confirmed. I can reproduce this with the anint_1.f90 test when compiled with -fprofile-generate and then -fprofile-use. The problem is the optimize_insn_for_size_p tests.
[Bug c++/68427] GCC (G++) flunks legal ANSI-C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68427 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely --- Why are you talking about ANSI-C when this is clearly C++ code? The file gauss.cpp compiles fine for me, you must have a problem with your makefile.
[Bug target/68408] broken support for attribute init_priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68408 --- Comment #3 from Eric Botcazou --- Author: ebotcazou Date: Thu Nov 19 11:49:32 2015 New Revision: 230598 URL: https://gcc.gnu.org/viewcvs?rev=230598&root=gcc&view=rev Log: PR target/68408 * config/sparc/sp-elf.h (CTORS_SECTION_ASM_OP): Undefine. (DTORS_SECTION_ASM_OP): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sp-elf.h
[Bug target/68408] broken support for attribute init_priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68408 --- Comment #4 from Eric Botcazou --- Author: ebotcazou Date: Thu Nov 19 11:50:35 2015 New Revision: 230599 URL: https://gcc.gnu.org/viewcvs?rev=230599&root=gcc&view=rev Log: PR target/68408 * config/sparc/sp-elf.h (CTORS_SECTION_ASM_OP): Undefine. (DTORS_SECTION_ASM_OP): Likewise. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/sparc/sp-elf.h
[Bug target/68408] broken support for attribute init_priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68408 --- Comment #5 from Eric Botcazou --- Author: ebotcazou Date: Thu Nov 19 11:51:20 2015 New Revision: 230600 URL: https://gcc.gnu.org/viewcvs?rev=230600&root=gcc&view=rev Log: PR target/68408 * config/sparc/sp-elf.h (CTORS_SECTION_ASM_OP): Undefine. (DTORS_SECTION_ASM_OP): Likewise. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/sparc/sp-elf.h
[Bug target/68408] broken support for attribute init_priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68408 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.4 --- Comment #6 from Eric Botcazou --- Fixed everywhere.
[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68413 Alan Hayward changed: What|Removed |Added CC||alan.hayward at arm dot com --- Comment #2 from Alan Hayward --- The the first call to vectorizable_condition (the check stage) succeeded, but the second call (the build stage) failed, causing an assert. Reproduced with head r230297 When updated to latest head, r230596 , issue is no longer present. Looking at changes in the vectorisor, there have been some vector bool changes, r230309. The vector bool work previously clashed with my work, so I suspect those changes have fixed it.
[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68413 alahay01 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-11-19 Ever confirmed|0 |1
[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68413 --- Comment #3 from Ilya Enkovich --- r230309 refers to a vectorization of a comparison of boolean values. It shouldn't affect condition vectorizaion. Thus most probably check and build stages of vectorizable_condition are still inconsistent.
[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68413 --- Comment #4 from Ilya Enkovich --- BTW I had an impression it was vectorizable_reduction which failed to transform, not vectorizable_condition.
[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68413 --- Comment #5 from alahay01 at gcc dot gnu.org --- Yes, your right, I meant to say vectorizable_reduction - it's a reduction of a condition.
[Bug rtl-optimization/67954] [5 / 6 Regression] internal compiler error: in patch_jump_insn, at cfgrtl.c:1303
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67954 Ramana Radhakrishnan changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-19 CC||ramana at gcc dot gnu.org Summary|[5 Regression] internal |[5 / 6 Regression] internal |compiler error: in |compiler error: in |patch_jump_insn, at |patch_jump_insn, at |cfgrtl.c:1303 |cfgrtl.c:1303 Ever confirmed|0 |1 Known to fail||5.2.0, 6.0 --- Comment #2 from Ramana Radhakrishnan --- trunk and 5.2.1 20151108 fails with the command line options -march=armv4t -mthumb -mfloat-abi=soft -O2 and the testcase. reducing.
[Bug rtl-optimization/67954] [5 / 6 Regression] internal compiler error: in patch_jump_insn, at cfgrtl.c:1303
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67954 --- Comment #3 from Ramana Radhakrishnan --- Created attachment 36771 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36771&action=edit reduced testcase reduced testcase
[Bug lto/61313] configure incorrectly strips $target_alias from PLUGIN_LD_SUFFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61313 --- Comment #4 from Eric Botcazou --- Author: ebotcazou Date: Thu Nov 19 13:31:33 2015 New Revision: 230603 URL: https://gcc.gnu.org/viewcvs?rev=230603&root=gcc&view=rev Log: PR lto/61313 * configure.ac (PLUGIN_LD_SUFFIX): Do not touch the value specified by the user. * configure: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac
[Bug lto/61313] configure incorrectly strips $target_alias from PLUGIN_LD_SUFFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61313 --- Comment #5 from Eric Botcazou --- Author: ebotcazou Date: Thu Nov 19 13:32:10 2015 New Revision: 230604 URL: https://gcc.gnu.org/viewcvs?rev=230604&root=gcc&view=rev Log: PR lto/61313 * configure.ac (PLUGIN_LD_SUFFIX): Do not touch the value specified by the user. * configure: Regenerate. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/configure branches/gcc-5-branch/gcc/configure.ac
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #5 from Mikael Morin --- (In reply to Joost VandeVondele from comment #4) > In the original post I suggested that I already looked at the code, What changes did you try?
[Bug lto/61313] configure incorrectly strips $target_alias from PLUGIN_LD_SUFFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61313 --- Comment #6 from Eric Botcazou --- Author: ebotcazou Date: Thu Nov 19 13:32:54 2015 New Revision: 230605 URL: https://gcc.gnu.org/viewcvs?rev=230605&root=gcc&view=rev Log: PR lto/61313 * configure.ac (PLUGIN_LD_SUFFIX): Do not touch the value specified by the user. * configure: Regenerate. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/configure branches/gcc-4_9-branch/gcc/configure.ac
[Bug lto/61313] configure incorrectly strips $target_alias from PLUGIN_LD_SUFFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61313 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.4 --- Comment #7 from Eric Botcazou --- Fixed everywhere.
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401
--- Comment #6 from Joost VandeVondele
---
(In reply to Mikael Morin from comment #5)
> (In reply to Joost VandeVondele from comment #4)
> > In the original post I suggested that I already looked at the code,
>
> What changes did you try?
Baby steps :-) see below. Basically stuck when I realized that somehow the
'tree size' needs to get in.
Index: fortran/trans.c
===
--- fortran/trans.c (revision 227094)
+++ fortran/trans.c (working copy)
@@ -567,6 +567,8 @@ gfc_call_malloc (stmtblock_t * block, tr
tree tmp, msg, malloc_result, null_result, res, malloc_tree;
stmtblock_t block2;
+ char* msgstr;
+
size = gfc_evaluate_now (size, block);
if (TREE_TYPE (size) != TREE_TYPE (size_type_node))
@@ -593,8 +595,9 @@ gfc_call_malloc (stmtblock_t * block, tr
null_result = fold_build2_loc (input_location, EQ_EXPR,
boolean_type_node, res,
build_int_cst (pvoid_type_node, 0));
+ msgstr = xasprintf("Memory allocation of %ld bytes failed",0L);
msg = gfc_build_addr_expr (pchar_type_node,
- gfc_build_localized_cstring_const ("Memory allocation failed"));
+ gfc_build_localized_cstring_const (msgstr));
tmp = fold_build3_loc (input_location, COND_EXPR, void_type_node,
null_result,
build_call_expr_loc (input_location,
@@ -641,6 +644,7 @@ gfc_allocate_using_malloc (stmtblock_t *
{
tree tmp, error_cond;
stmtblock_t on_error;
+ char* msgstr;
tree status_type = status ? TREE_TYPE (status) : NULL_TREE;
/* Evaluate size only once, and make sure it has the right type. */
@@ -677,10 +681,12 @@ gfc_allocate_using_malloc (stmtblock_t *
else
{
/* Here, os_error already implies PRED_NORETURN. */
+ /* TODO figure out how to get 'size' in this string */
+ msgstr=xasprintf("Allocation of %ld bytes would exceed memory
limit",-1L);
tmp = build_call_expr_loc (input_location, gfor_fndecl_os_error, 1,
- gfc_build_addr_expr (pchar_type_node,
-gfc_build_localized_cstring_const
- ("Allocation would exceed memory limit")));
+ gfc_build_addr_expr (pchar_type_node,
gfc_build_cstring_const(msgstr)));
+ /* gfc_build_localized_cstring_const
+ ("Allocation would exceed memory limit")));
*/
gfc_add_expr_to_block (&on_error, tmp);
}
[Bug c++/68434] New: [concepts] ICE same canonical type node for different types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68434
Bug ID: 68434
Summary: [concepts] ICE same canonical type node for different
types
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ryan.burn at gmail dot com
Target Milestone: ---
The code below generates this ICE when compiled with
g++ (GCC) 6.0.0 20151118 (experimental)
constexpr bool C1() constexpr bool C2() constexpr bool C3()
reduce2.cpp: At global scope:
reduce2.cpp:19:10: internal compiler error: same canonical type node for
different types C2 and C1
auto f(C3) {
^
0x8fb760 comptypes(tree_node*, tree_node*, int)
../../src-orig/gcc/cp/typeck.c:1435
0x9857e8 cp_tree_equal(tree_node*, tree_node*)
../../src-orig/gcc/cp/tree.c:3128
0x9857a1 cp_tree_equal(tree_node*, tree_node*)
../../src-orig/gcc/cp/tree.c:3121
0x9857a1 cp_tree_equal(tree_node*, tree_node*)
../../src-orig/gcc/cp/tree.c:3121
0xa17928 insert
../../src-orig/gcc/cp/logic.cc:131
0xa17c8d left_conjunction
../../src-orig/gcc/cp/logic.cc:237
0xa17e6d decompose_left_term
../../src-orig/gcc/cp/logic.cc:292
0xa17f07 decompose_left_goal
../../src-orig/gcc/cp/logic.cc:315
0xa17f5d decompose_left
../../src-orig/gcc/cp/logic.cc:327
0xa18179 decompose_assumptions(tree_node*)
../../src-orig/gcc/cp/logic.cc:373
0xa12af0 build_constraints(tree_node*, tree_node*)
../../src-orig/gcc/cp/constraint.cc:1035
0x780e0f grokfndecl
../../src-orig/gcc/cp/decl.c:7819
0x78c25d grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../src-orig/gcc/cp/decl.c:11292
0x79f2c9 start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
../../src-orig/gcc/cp/decl.c:14069
0x8bd2c1 cp_parser_function_definition_from_specifiers_and_declarator
../../src-orig/gcc/cp/parser.c:24703
0x8b09bd cp_parser_init_declarator
../../src-orig/gcc/cp/parser.c:17972
0x8a6d64 cp_parser_simple_declaration
../../src-orig/gcc/cp/parser.c:11971
0x8a6b22 cp_parser_block_declaration
../../src-orig/gcc/cp/parser.c:11843
0x8a689c cp_parser_declaration
../../src-orig/gcc/cp/parser.c:11740
0x8a63a7 cp_parser_declaration_seq_opt
../../src-orig/gcc/cp/parser.c:11619
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions
//
template
concept bool C1() {
return true;
}
template
concept bool C2() {
return true;
}
template
concept bool C3() {
return requires(Expr expr) {
{expr}->C1;
{expr}->C2;
};
}
auto f(C3) {
}
//
[Bug c++/68427] GCC (G++) flunks legal ANSI-C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68427 --- Comment #3 from wam at hiwaay dot net --- comment 1: How do I go about doing that (posting preprocessed source file) ? The tarball I uploaded just has 2 text files showing the output of my effort to compile the code, & the code in its own tarball. comment 2: The code was ANSI-C for about 15 years (from ~1995 on), then converted to C++ by simply renaming it to gauss.cpp & overloading the names of the various gauss functions. It is otherwise legal ANSI C code. As to the makefile, I used GCC 4.8.5, pkg-installed, i.e. compiled up by the FreeBSD folks & retreived by me from their repo. I compiled the GCC5.2.1 up myself, adding Graphite support (recently accomodated by the GCC maintainer(s)). I did nothing to the makefile myself. I originally posted this to the FreeBSD-toolchain list & was advised to repost it here. When you compile it, are you using FreeBSD 9.3R to do so, or another implementation ?
[Bug middle-end/68393] internal compiler error: in convert_move, at expr.c:286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68393 --- Comment #7 from Bill Schmidt --- Thanks, Richard!
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 --- Comment #7 from Mikael Morin --- (In reply to Joost VandeVondele from comment #6) > (In reply to Mikael Morin from comment #5) > > (In reply to Joost VandeVondele from comment #4) > > > In the original post I suggested that I already looked at the code, > > > > What changes did you try? > > Baby steps :-) see below. Basically stuck when I realized that somehow the > 'tree size' needs to get in. > I guess the easiest is to use a variadic call. The calls can be updated by incrementing the argument count of build_call_expr_loc, and adding the size argument. Then you can't use os_error, which is non-variadic. You can either use one of the existing (variadic) routines, such as runtime_error, or create some os_error_varargs (basically create the gfor_fndecl_XXX in trans-decl.c and use it as argument of build_call_expr_loc). If you create a new declaration, you'll have to write the corresponding code in libgfortran. Does it sound like it's worth it?
[Bug fortran/68401] improve 'Allocation would exceed memory limit'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401 --- Comment #8 from Joost VandeVondele --- (In reply to Mikael Morin from comment #7) > (In reply to Joost VandeVondele from comment #6) > > (In reply to Mikael Morin from comment #5) > > > (In reply to Joost VandeVondele from comment #4) > > > > In the original post I suggested that I already looked at the code, > > > > > > What changes did you try? > > > > Baby steps :-) see below. Basically stuck when I realized that somehow the > > 'tree size' needs to get in. > > > I guess the easiest is to use a variadic call. > The calls can be updated by incrementing the argument count of > build_call_expr_loc, and adding the size argument. > Then you can't use os_error, which is non-variadic. > You can either use one of the existing (variadic) routines, such as > runtime_error, or create some os_error_varargs (basically create the > gfor_fndecl_XXX in trans-decl.c and use it as argument of > build_call_expr_loc). > If you create a new declaration, you'll have to write the corresponding code > in libgfortran. > > Does it sound like it's worth it? well, at least I have an idea of a way forward.. I did spent a few hours on this already. I guess it is easier once one knows the code. I do believe this is useful indeed, within our project we discussed if we could clean up the error checking of (de)allocates (14000 calls) and we already removed all checking for all but 400, cleaning away roughly 3 lines of (useless in my opinion, and with various bugs) code. See for example https://sourceforge.net/p/cp2k/code/15938/ with many similar commits. The remaining 400 calls report the size of the failed allocate. To clean those the consensus was that the compiler should report the size of the failed allocation.
[Bug target/68408] broken support for attribute init_priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68408 --- Comment #7 from Sergey Organov --- Eric, thank you very much for the quick fix! I confirm it is fixed on sparc-elf-g++ (GCC) 5.2.1 20151119.
[Bug rtl-optimization/68435] New: [6 Regression] Missed if-conversion optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68435
Bug ID: 68435
Summary: [6 Regression] Missed if-conversion optimization
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: afomin.mailbox at gmail dot com
CC: izamyatin at gmail dot com, kyrylo.tkachov at arm dot com,
ysrumyan at gmail dot com
Target Milestone: ---
Build: x86_64-linux-gnu
Created attachment 36772
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36772&action=edit
A reproducer
Given the following code compiled with -fif-conversion, we miss if-conversion
opportunity since r228194.
int
foo(char *p1, char *p2, int n)
{
int s = 0;
int v;
int i;
for (i = 0; i < n; i++) {
v = p1[i] - p2[i];
if (v >= 0)
s += v;
else
s -= v;
p1 = p2++;
}
return s;
}
[Bug target/57845] ICE with -freg-struct-return on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57845 --- Comment #16 from Sergey Organov --- I confirm it is fixed on sparc-elf-gcc (GCC) 5.2.1 20151119. Thanks one more time!
[Bug rtl-optimization/68435] [6 Regression] Missed if-conversion optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68435 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #1 from ktkachov at gcc dot gnu.org --- I'll have a look, thanks. Is this on x86_64? Could you please post the if-converted code before that revision?
[Bug tree-optimization/68431] [6 Regression] Regression in GCC-6.0.0's optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68431 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed.
[Bug tree-optimization/68431] [6 Regression] Regression in GCC-6.0.0's optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68431 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Thu Nov 19 15:12:35 2015 New Revision: 230608 URL: https://gcc.gnu.org/viewcvs?rev=230608&root=gcc&view=rev Log: PR tree-optimization/68431 * tree-vrp.c (extract_range_from_binary_expr_1): Fix condition. * gcc.dg/tree-ssa/pr68431.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr68431.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug target/68408] broken support for attribute init_priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68408 --- Comment #8 from Eric Botcazou --- > Eric, thank you very much for the quick fix! You're welcome. > I confirm it is fixed on sparc-elf-g++ (GCC) 5.2.1 20151119. Thanks, independent verification is always helpful.
[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68413 --- Comment #6 from Ilya Enkovich --- I checked what is happening and seems the reason is in different STMT_VINFO_VEC_REDUCTION_TYPE (stmt_info) on analysis and transform phases. During analysis it is INTEGER_INDUC_COND_REDUCTION, for transformation it is COND_REDUCTION. Thus we have different flow for if-statement at tree-vect-loop.c:5653 whose branches have two major differences. 1. Different types are used to get optab. For analysis we get reduc_smax_scal_optab, for transformation we get reduc_umax_scal_optab. 2. Only 'true path' checks old optabs (with no _scal_) This bug was 'fixed' by r230423 which switched i386 target to new optabs, but problem still exist. Currently I see on trunk: Analysis: #0 optab_handler (op=reduc_smax_scal_optab, mode=V8SImode) at gcc/optabs-query.h:31 #1 0x01023d5d in vectorizable_reduction (stmt=0x77f20660, gsi=0x0, vec_stmt=0x0, slp_node=0x0) at gcc/tree-vect-loop.c:5643 Transformation: #0 optab_handler (op=reduc_umax_scal_optab, mode=V8SImode) at gcc/optabs-query.h:31 #1 0x01023fb1 in vectorizable_reduction (stmt=0x77f20660, gsi=0x7fffb600, vec_stmt=0x7fffb558, slp_node=0x0) at gcc/tree-vect-loop.c:5691 Note the same statements but different optabs used. Also we my still have ICE on targets not using new reduction optabs.
[Bug middle-end/68436] New: [5 Regression] wrong code on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68436
Bug ID: 68436
Summary: [5 Regression] wrong code on x86_64-linux-gnu
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
Created attachment 36773
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36773&action=edit
preprocessed source
[forwarded from https://bugs.debian.org/800543]
last rechecked with 20151028 from the branch.
On line 15054 of the attached preprocessed output of 'file.c', the
following code:
x->sm.sm_buffer = 0;
x->sm.sm_object0 = (unzipped ? make_cons(sSAallow_gzipped_fileA,unzipped) :
sLcharacter);
x->sm.sm_object1 = fn;
x->sm.sm_int0 = x->sm.sm_int1 = 0;
(*vs_top++ = (x));
setup_stream_buffer(x);
referring to the function setup_stream_buffer on line 14810 in the same file:
void
setup_stream_buffer(object x) {
if (!(!setvbuf(x->sm.sm_fp,x->sm.sm_buffer=({void * v;bool
w=writable_malloc;writable_malloc=1;v=malloc(
# 314 "file.d" 3 4
8192
# 314 "file.d"
);writable_malloc=w;v;}),
# 314 "file.d" 3 4
0
# 314 "file.d"
,
# 314 "file.d" 3 4
8192
# 314 "file.d"
)))
assert_error("!setvbuf(x->sm.sm_fp,x->sm.sm_buffer=writable_malloc_wrap(malloc,void
*,BUFSIZ),_IOFBF,BUFSIZ)",314,"file.d",__FUNCTION__);
}
is miscompiled at -O3, with the line
x->sm.sm_buffer = 0;
omitted and optimized away. Apparently there is some sort of escape
analysis in which the write to x->sm.sm_buffer in setup_stream_buffer is
detected and determined to be side effect free, maybe because 'malloc'
is assumed to have certain properties. This is GCL, however, which
supplies its own malloc on top of a native garbage collector, which then
fails when examining 'x' with an uninitialized sm.sm_buffer field.
-O2 works fine.
[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68413 --- Comment #7 from Ilya Enkovich --- Looking deeper the difference is caused by different result of is_nonwrapping_integer_induction called for reduction related phi statement. For the first call it is: i_12 = PHI For the second call it is: i_12 = PHI It changed due to generated prologue. It cases is_nonwrapping_integer_induction to return false due to non-constant base and as a result we compute different reduction type. Probably compute reduction type at analysis phase only?
[Bug rtl-optimization/68435] [6 Regression] Missed if-conversion optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68435 --- Comment #2 from Yuri Rumyantsev --- I will post 2 rtl dumps for ce1 phase produced with -O2 -m32 options on ix86. You can see that file t21.c.203r.ce1 produced by 20110927 compiler contains 3 possible IF blocks searched. 1 IF blocks converted. 2 true changes made. but file t21.c.209r.ce1 produced by 20151119 compiler does not 1 possible IF blocks searched. 0 IF blocks converted. 0 true changes made.
[Bug rtl-optimization/68435] [6 Regression] Missed if-conversion optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68435 --- Comment #3 from Alexander Fomin --- This can be reproduced both for i686-*-* and x86_64-*-* hosts.
[Bug rtl-optimization/68435] [6 Regression] Missed if-conversion optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68435 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-11-19 Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #5 from ktkachov at gcc dot gnu.org --- Thanks to both of you for the info. I've reproduced this.
[Bug rtl-optimization/68435] [6 Regression] Missed if-conversion optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68435 --- Comment #4 from Yuri Rumyantsev --- Created attachment 36774 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36774&action=edit tar file tar file contains good and bad ce1-rtl dumps showing the problem
[Bug c++/68437] New: [concepts] fold expression, pack expansion, and deduced constraint requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68437 Bug ID: 68437 Summary: [concepts] fold expression, pack expansion, and deduced constraint requirement Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- Created attachment 36775 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36775&action=edit Minimal testcase This is using g++-trunk (GCC) 6.0.0 20151103 (experimental). Attached testcase is as minimal as I could manage. If I change the fold expression in the requirement to a 'manual', compile-time fold (not included in the testcase for brevity) then the program compiles as expected--this is the workaround that I'm using in the meantime.
[Bug c++/67409] [5/6 Regression] tree-cfg.c dereferences a NULL pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67409 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Thu Nov 19 16:18:39 2015 New Revision: 230613 URL: https://gcc.gnu.org/viewcvs?rev=230613&root=gcc&view=rev Log: PR c++/67409 * decl.c (identify_goto): Add LOC and DIAG_KIND arguments, call emit_diagnostic instead of permerror. (check_previous_goto_1): Adjust identify_goto callers, treat all cases but crossing initialization and entering scope of decl with non-trivial dtor as unconditional hard errors. (check_goto): Use identify_goto. Treat all cases but crossing initialization and entering scope of decl with non-trivial dtor as unconditional hard errors. * g++.dg/eh/goto3.C: New test. Added: trunk/gcc/testsuite/g++.dg/eh/goto3.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/68392] ICE: SIGSEGV in update_uses (fwprop.c:896) with -fno-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68392 Michael Matz changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #6 from Michael Matz --- Should be fixed with r230612. Can you confirm?
[Bug other/67868] ICE in handling VTV sections for targets with section anchors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67868 --- Comment #10 from Bill Schmidt --- Thanks, Ramana! I've verified that this is working ok for Power as well.
[Bug tree-optimization/68413] [6 Regression] internal compiler error: in vect_transform_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68413 alahay01 at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |alahay01 at gcc dot gnu.org --- Comment #8 from alahay01 at gcc dot gnu.org --- >Probably compute reduction type at analysis phase only? I had come to the same conclusion myself :) Initially I was going to ignore base in is_nonwrapping_integer_induction (), but that is not a good idea. I'm writing a patch now. There's a few places more places than I expected to add checks for the analysis phase.
[Bug c++/67409] [5/6 Regression] tree-cfg.c dereferences a NULL pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67409 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Thu Nov 19 16:34:32 2015 New Revision: 230616 URL: https://gcc.gnu.org/viewcvs?rev=230616&root=gcc&view=rev Log: PR c++/67409 * decl.c (identify_goto): Add LOC and DIAG_KIND arguments, call emit_diagnostic instead of permerror. (check_previous_goto_1): Adjust identify_goto callers, treat all cases but crossing initialization and entering scope of decl with non-trivial dtor as unconditional hard errors. (check_goto): Use identify_goto. Treat all cases but crossing initialization and entering scope of decl with non-trivial dtor as unconditional hard errors. * g++.dg/eh/goto3.C: New test. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/eh/goto3.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/decl.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug c++/68409] Garbage added to a map instead of object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68409 --- Comment #1 from f3rn4nd0.c354r --- I forget to specify the compilation options used: -std=c++11 -Wall -Wextra -save-temps
[Bug rtl-optimization/68376] [4.9 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68376 Jakub Jelinek changed: What|Removed |Added Summary|[4.9/5/6 Regression] wrong |[4.9 Regression] wrong code |code at -O1 and above on|at -O1 and above on |x86_64-linux-gnu|x86_64-linux-gnu --- Comment #7 from Jakub Jelinek --- Fixed for 5.3+ so far.
[Bug c++/67409] [5/6 Regression] tree-cfg.c dereferences a NULL pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67409 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek --- Fixed for 5.3+.
[Bug target/67770] [4.9 Regression] i386: -fshrink-wrap can interact badly with trampolines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67770 Jakub Jelinek changed: What|Removed |Added Summary|[4.9/5/6 Regression] i386: |[4.9 Regression] i386: |-fshrink-wrap can interact |-fshrink-wrap can interact |badly with trampolines |badly with trampolines --- Comment #7 from Jakub Jelinek --- Fixed for 5.3+ so far.
[Bug preprocessor/60736] [4.9 Regression] Crash in preprocessor including stdc-predef.h when it does not exist on glibc-based systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736 Jakub Jelinek changed: What|Removed |Added Summary|[4.9/5/6 Regression] Crash |[4.9 Regression] Crash in |in preprocessor including |preprocessor including |stdc-predef.h when it does |stdc-predef.h when it does |not exist on glibc-based|not exist on glibc-based |systems |systems --- Comment #17 from Jakub Jelinek --- Fixed for 5.3+ so far.
[Bug tree-optimization/46032] openmp inhibits loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46032 --- Comment #20 from vries at gcc dot gnu.org --- This patch seems to have the desired effect on the original testcase: ... diff --git a/gcc/omp-low.c b/gcc/omp-low.c index 830db75..996756b 100644 --- a/gcc/omp-low.c +++ b/gcc/omp-low.c @@ -9361,6 +9361,7 @@ expand_omp_for_static_nochunk (struct omp_region *region, if (collapse_bb == NULL) loop->latch = cont_bb; add_loop (loop, body_bb->loop_father); + loop->safelen = INT_MAX; } } ... AFAIU, adding the omp for to the loop is an assertion that the loop is independent. It seems reasonable to assume that if the original loop was independent, the loop operating on a slice of the original iteration space will be independent as well.
[Bug rtl-optimization/68392] ICE: SIGSEGV in update_uses (fwprop.c:896) with -fno-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68392
Mikhail Maltsev changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-11-19
Ever confirmed|0 |1
--- Comment #7 from Mikhail Maltsev ---
Yes, it helps. Also consider adding this testcase to g++.dg (used to ICE on
x86_64):
// PR rtl-optimization/68392
// { dg-do compile }
// { dg-options "-O -fno-checking" }
void tool_cleanup(bool from_signal)
{
tool_cleanup(from_signal);
}
[Bug tree-optimization/46032] openmp inhibits loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46032 --- Comment #21 from Jakub Jelinek --- (In reply to vries from comment #20) > This patch seems to have the desired effect on the original testcase: > ... > diff --git a/gcc/omp-low.c b/gcc/omp-low.c > index 830db75..996756b 100644 > --- a/gcc/omp-low.c > +++ b/gcc/omp-low.c > @@ -9361,6 +9361,7 @@ expand_omp_for_static_nochunk (struct omp_region > *region, >if (collapse_bb == NULL) > loop->latch = cont_bb; >add_loop (loop, body_bb->loop_father); > + loop->safelen = INT_MAX; > } > } > ... > > AFAIU, adding the omp for to the loop is an assertion that the loop is > independent. It seems reasonable to assume that if the original loop was > independent, the loop operating on a slice of the original iteration space > will be independent as well. That is very much wrong. Static scheduling, both nochunk and chunk, doesn't imply in any way that the iterations are independent, the OpenMP standard says how the work is split among the threads, with nochunk that threads get consecutive sets of iterations as one chunk that are approximately the same size, but eventhough it is not exactly specified how exactly the iteration space is deviced (for nochunk), if you make the loop iterations independent, you would break many observable properties (say through threadprivate vars, omp_get_thread_num etc.). Note loop->safelen == INT_MAX is actually weaker than independent iterations, when loop->safelen == INT_MAX, there can be dependencies, but only of certain kinds, it says that it is equivalent if you run the loop normally and if you run simultaneously (or emulated) the first statements of all the iterations, then second statements and so on (so vectorize with any vectorization factor the compiler wants).
[Bug objc/68438] New: [6 Regression] Conditional jump or move depends on uninitialised value in location_adhoc_data_eq (line-map.c:89)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68438
Bug ID: 68438
Summary: [6 Regression] Conditional jump or move depends on
uninitialised value in location_adhoc_data_eq
(line-map.c:89)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Hi.
Looks objc test-suite contains many valgrind errors:
Command:
valgrind --leak-check=yes --trace-children=yes --num-callers=100 gcc
/home/marxin/Programming/gcc/gcc/testsuite/objc.dg/call-super-2.m -c
==8665== Conditional jump or move depends on uninitialised value(s)
==8665==at 0x169A8D6: location_adhoc_data_eq(void const*, void const*)
(line-map.c:89)
==8665==by 0x16CDB3C: htab_find_slot_with_hash (hashtab.c:679)
==8665==by 0x169B5DC: get_combined_adhoc_loc(line_maps*, unsigned int,
source_range, void*) (line-map.c:214)
==8665==by 0xFFEAE9: COMBINE_LOCATION_DATA(line_maps*, unsigned int,
source_range, void*) (line-map.h:1004)
==8665==by 0xFFCE0B: set_source_range(tree_node*, source_range)
(tree.c:13936)
==8665==by 0xFFCD5A: set_source_range(tree_node*, unsigned int, unsigned
int) (tree.c:13923)
==8665==by 0x804E73: c_fully_fold_internal(tree_node*, bool, bool*, bool*,
bool) (c-common.c:1639)
==8665==by 0x803C7A: c_fully_fold_internal(tree_node*, bool, bool*, bool*,
bool) (c-common.c:1372)
==8665==by 0x803497: c_fully_fold(tree_node*, bool, bool*)
(c-common.c:1162)
==8665==by 0x7CA952: build_modify_expr(unsigned int, tree_node*,
tree_node*, tree_code, unsigned int, tree_node*, tree_node*) (c-typeck.c:5545)
==8665==by 0x7DA5F8: c_parser_expr_no_commas(c_parser*, c_expr*,
tree_node*) (c-parser.c:6149)
==8665==by 0x7E0CFF: c_parser_expression(c_parser*) (c-parser.c:8250)
==8665==by 0x7E0F38: c_parser_expression_conv(c_parser*) (c-parser.c:8283)
==8665==by 0x7D82FF: c_parser_statement_after_labels(c_parser*,
vec*) (c-parser.c:5177)
==8665==by 0x7D781D: c_parser_compound_statement_nostart(c_parser*)
(c-parser.c:4762)
==8665==by 0x7D724D: c_parser_compound_statement(c_parser*)
(c-parser.c:4599)
==8665==by 0x7E1FFC: c_parser_objc_method_definition(c_parser*)
(c-parser.c:8821)
==8665==by 0x7D0FA9: c_parser_external_declaration(c_parser*)
(c-parser.c:1449)
==8665==by 0x7D0BF1: c_parser_translation_unit(c_parser*) (c-parser.c:1348)
==8665==by 0x7FB922: c_parse_file() (c-parser.c:17658)
==8665==by 0x850A92: c_common_parse_file() (c-opts.c:1064)
==8665==by 0xD41AF8: compile_file() (toplev.c:464)
==8665==by 0xD43F4F: do_compile() (toplev.c:1951)
==8665==by 0xD441CE: toplev::main(int, char**) (toplev.c:2058)
==8665==by 0x166391D: main (main.c:39)
==8665==
/home/marxin/Programming/gcc/gcc/testsuite/objc.dg/call-super-2.m:134:4:
warning: ‘-categ_instance_func2’ not found in protocol(s)
i += (size_t)[(id )self categ_instance_func2]; /* { dg-warning
".\\-categ_instance_func2. not found in protocol" } */
^
/home/marxin/Programming/gcc/gcc/testsuite/objc.dg/call-super-2.m:136:4:
warning: ‘TestsuiteObject’ may not respond to ‘-instance_func0’
return i + (size_t)[super instance_func0]; /* { dg-warning
".TestsuiteObject. may not respond to .\\-instance_func0." } */
^~
==8665== Use of uninitialised value of size 8
==8665==at 0x16CDA83: htab_find_slot_with_hash (hashtab.c:655)
==8665==by 0x169B5DC: get_combined_adhoc_loc(line_maps*, unsigned int,
source_range, void*) (line-map.c:214)
==8665==by 0xFFEAE9: COMBINE_LOCATION_DATA(line_maps*, unsigned int,
source_range, void*) (line-map.h:1004)
==8665==by 0xFFCD27: set_block(unsigned int, tree_node*) (tree.c:13914)
==8665==by 0x156A9C4: gimple_set_block(gimple*, tree_node*) (gimple.h:1744)
==8665==by 0x156B4A6: lower_stmt(gimple_stmt_iterator*, lower_data*)
(gimple-low.c:236)
==8665==by 0x156B3D8: lower_sequence(gimple**, lower_data*)
(gimple-low.c:203)
==8665==by 0x156B586: lower_stmt(gimple_stmt_iterator*, lower_data*)
(gimple-low.c:272)
==8665==by 0x156B3D8: lower_sequence(gimple**, lower_data*)
(gimple-low.c:203)
==8665==by 0x156B94E: lower_gimple_bind(gimple_stmt_iterator*, lower_data*)
(gimple-low.c:418)
==8665==by 0x156B0EB: lower_function_body() (gimple-low.c:107)
==8665==by 0x156B33C: (anonymous
namespace)::pass_lower_cf::execute(function*) (gimple-low.c:181)
==8665==by 0xC39BF9: execute_one_pass(opt_pass*) (passes.c:2335)
==8665==by 0xC39EFC: execute_pass_list_1(opt_pass*) (passes.c:2408)
==8665==by 0xC39F85: execute_pass_list(function*, opt_pass*)
(passes.c:2419)
==8665==by 0x904119: cgraph_node::analyze() (cgraphunit.c:634)
==8665==by 0x9051B9: analyze_functions(bool) (cgraphunit.c:1078)
==8665==by 0x908B48: symbol_table::finalize_compilation_unit()
(cgrap
[Bug target/68421] unused copy of global register variable into another gpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68421
--- Comment #2 from acsawdey at gcc dot gnu.org ---
So, looking at the dump files, at the end of tree form we have copies from the
register globals and uses of the copies only:
:
execute_data.0_4 = execute_data;
opline.1_5 = opline;
_6 = opline.1_5->op1.var;
Then after reload, those temps get allocated to 8 and 10 and only 8/10 are used
after the initial copy:
(insn 8 2 7 2 (set (reg/f:DI 8 8 [orig:157 opline.1_5 ] [157])
(reg/v:DI 29 29 [ opline ])) min_unused_regs10.c:51 538
{*movdi_internal64}
(nil))
(insn 7 8 9 2 (set (reg/f:DI 10 10 [orig:156 execute_data.0_4 ] [156])
(reg/v:DI 28 28 [ execute_data ])) min_unused_regs10.c:51 538
{*movdi_internal64}
(nil))
(insn 9 7 10 2 (set (reg:DI 6 6 [orig:172 opline.1_5->op1.var ] [172])
(sign_extend:DI (mem:SI (reg/f:DI 8 8 [orig:157 opline.1_5 ] [157]) [0
opline.1_5->op1.var+0 S4 A32]))) min_unused_regs10.c:41 46 {extendsidi2}
(nil))
(insn 10 9 11 2 (set (reg/f:DI 9 9 [orig:169 _29 ] [169])
(plus:DI (reg/f:DI 10 10 [orig:156 execute_data.0_4 ] [156])
(reg:DI 6 6 [orig:172 opline.1_5->op1.var ] [172])))
min_unused_regs10.c:41 81 {*adddi3}
(nil))
Then after cprop_hardreg, the uses of 8/10 are replaced with 29/28 except for
that initial copy which is what remains:
(insn 8 2 7 2 (set (reg/f:DI 8 8 [orig:157 opline.1_5 ] [157])
(reg/v:DI 29 29 [ opline ])) min_unused_regs10.c:51 538
{*movdi_internal64}
(nil))
(insn 7 8 9 2 (set (reg/f:DI 10 10 [orig:156 execute_data.0_4 ] [156])
(reg/v:DI 28 28 [ execute_data ])) min_unused_regs10.c:51 538
{*movdi_internal64}
(nil))
(insn 9 7 10 2 (set (reg:DI 6 6 [orig:172 opline.1_5->op1.var ] [172])
(sign_extend:DI (mem:SI (reg/f:DI 29 29 [orig:157 opline.1_5 ] [157])
[0 opline.1_5->op1.var+0 S4 A32]))) min_unused_regs10.c:41 46 {extendsidi2}
(nil))
(insn 10 9 11 2 (set (reg/f:DI 9 9 [orig:169 _29 ] [169])
(plus:DI (reg/f:DI 28 28 [orig:156 execute_data.0_4 ] [156])
(reg:DI 6 6 [orig:172 opline.1_5->op1.var ] [172])))
min_unused_regs10.c:41 81 {*adddi3}
(nil))
[Bug target/67089] [4.9/5/6 Regression] Integer overflow checks not optimized on x86/x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67089 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Note this affects even code generated with __builtin_sub_overflow.
[Bug testsuite/66621] [4.9/5 Regression] Mistakenly unsupported tests in g++.dg/torture/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66621 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- I guess not severe enough to backport. Thus fixed for 6.1+.
[Bug fortran/68439] New: ICE in alloc_scalar_allocatable_for_subcomponent_assignment, at fortran/trans-expr.c:6711
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68439 Bug ID: 68439 Summary: ICE in alloc_scalar_allocatable_for_subcomponent_assignment, at fortran/trans-expr.c:6711 Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- One dedicated case and error message. Issue related with pr68225. $ cat z1.f90 program p type t integer :: a character(:), allocatable :: c end type type(t) :: x x = t(a=1) end $ gfortran -g -O0 -Wall -fcheck=all -c z1.f90 z1.f90:7:0: x = t(a=1) 1 internal compiler error: in alloc_scalar_allocatable_for_subcomponent_assignment, at fortran/trans-expr.c:6711
[Bug fortran/68440] New: ICE on declaring class variable with wrong attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68440 Bug ID: 68440 Summary: ICE on declaring class variable with wrong attribute Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This wrong code (class not allocatable nor pointer) : $ cat z1.f90 subroutine s type t end type class(t), parameter :: x = t() class(t), parameter :: y = x end $ gfortran -g -O0 -Wall -fcheck=all z1.f90 f951: internal compiler error: in check_alloc_comp_init, at fortran/expr.c:2209 --- $ cat z2.f90 subroutine s type t end type class(t), parameter :: x = t() class(t) :: y = x end $ gfortran -g -O0 -Wall -fcheck=all z2.f90 f951: internal compiler error: in check_alloc_comp_init, at fortran/expr.c:2209
[Bug fortran/68440] ICE on declaring class variable with wrong attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68440 --- Comment #1 from Gerhard Steinmetz --- Some variants : $ cat z4.f90 subroutine s type t end type class(t), parameter :: x = t() end $ gfortran -g -O0 -Wall -fcheck=all z4.f90 f951: internal compiler error: Segmentation fault --- $ cat z5.f90 subroutine s type t end type class(t) :: x = t() end $ gfortran -g -O0 -Wall -fcheck=all z5.f90 z5.f90:4:16: class(t) :: x = t() 1 Error: CLASS variable 'x' at (1) must be dummy, allocatable or pointer (null):0: confused by earlier errors, bailing out
[Bug fortran/68440] ICE on declaring class variable with wrong attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68440 --- Comment #2 from Gerhard Steinmetz --- Detected : $ cat z7.f90 subroutine s type t end type class(t), allocatable :: x = t() end $ gfortran -g -O0 -Wall -fcheck=all z7.f90 z7.f90:4:29: class(t), allocatable :: x = t() 1 Error: Allocatable 'x' at (1) cannot have an initializer --- $ cat z8.f90 subroutine s type t end type class(t), allocatable :: x x = t() end $ gfortran -g -O0 -Wall -fcheck=all z8.f90 z8.f90:5:3: x = t() 1 Error: Assignment to an allocatable polymorphic variable at (1) is not yet supported
[Bug fortran/68441] New: ICE on using transfer with character parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68441 Bug ID: 68441 Summary: ICE on using transfer with character parameter Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- For some tests of "TRANSFER (TRANSFER (E, D), E)" : $ cat z1.f90 program p character(huge(1_1)), parameter :: x = 'abc' print *, transfer(transfer(0, x), 0) end $ gfortran-5 -g -O0 -Wall -fcheck=all z1.f90 f951: internal compiler error: in gfc_interpret_character, at fortran/target-memory.c:458 --- Whereas : $ cat z2.f90 program p character(huge(1_1)) :: x = 'abc' print *, transfer(transfer(0, x), 0) end $ gfortran-5 -g -O0 -Wall -fcheck=all z2.f90 z2.f90:3:30: print *, transfer(transfer(0, x), 0) 1 Warning: Intrinsic TRANSFER at (1) has partly undefined result: source size 4 < result size 127 $ a.out 0
[Bug fortran/68442] New: ICE on kind specification, depending on ordering of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68442 Bug ID: 68442 Summary: ICE on kind specification, depending on ordering of functions Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Using this order (f before g) : $ cat z1.f90 module m interface gkind procedure g end interface contains subroutine f(x) character(kind=gkind()) :: x end integer function g() g = 1 end end $ gfortran-5 -g -O0 -Wall -fcheck=all z1.f90 f951: internal compiler error: in gfc_arglist_matches_symbol, at fortran/interface.c:3468
[Bug fortran/68442] ICE on kind specification, depending on ordering of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68442 --- Comment #1 from Gerhard Steinmetz --- Detected with reversed order : $ cat z2.f90 module m interface gkind procedure g end interface contains integer function g() g = 1 end subroutine f(x) character(kind=gkind()) :: x end end $ gfortran-5 -g -O0 -Wall -fcheck=all z2.f90 z2.f90:10:21: character(kind=gkind()) :: x 1 Error: Function 'gkind' in initialization expression at (1) must be an intrinsic function
[Bug c++/68427] GCC (G++) flunks legal ANSI-C code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68427 --- Comment #4 from Jonathan Wakely --- (In reply to wam from comment #3) > comment 1: How do I go about doing that (posting preprocessed source file) ? It's explained at the link you should have read before creating a bug: https://gcc.gnu.org/bugs/ > The tarball I uploaded just has 2 text files showing the output of my effort > to compile the code, & the code in its own tarball. Yes I know, I used the same commands as you showed in your file, and it compiled successfully. > comment 2: The code was ANSI-C for about 15 years (from ~1995 on), then > converted to C++ by simply renaming it to gauss.cpp & overloading the names > of the various gauss functions. It is otherwise legal ANSI C code. But that's irrelevant. It's *not* ANSI C code if you've used overloaded functions, and you're compiling it as C++ anyway so it's besides the point. C and C++ are different languages, just because something used to be valid C doesn't mean failing to compile as C++ indicates a compiler bug. > As to the > makefile, I used GCC 4.8.5, pkg-installed, i.e. compiled up by the FreeBSD > folks & retreived by me from their repo. I compiled the GCC5.2.1 up myself, > adding Graphite support (recently accomodated by the GCC maintainer(s)). I > did nothing to the makefile myself. I originally posted this to the > FreeBSD-toolchain list & was advised to repost it here. When you compile it, > are you using FreeBSD 9.3R to do so, or another implementation ? I only tried on GNU/Linux. The errors shown in your file are not platform-specific, they suggest a header file was missing or something like that.
[Bug ada/68443] New: [ada] FAIL: c39006b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68443 Bug ID: 68443 Summary: [ada] FAIL: c39006b Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- With r230596: ... RUN c39006b ,.,. C39006B ACATS 2.5 15-11-19 04:41:57 C39006B CHECK THAT PROGRAM_ERROR IS RAISED IF AN ATTEMPT IS MADE TO CALL A SUBPROGRAM WHOSE BODY HAS NOT YET BEEN ELABORATED. * C39006B PROGRAM_ERROR NOT RAISED - 2. C39006B FAILED . FAIL: c39006b ...
