[Bug testsuite/83909] Make doesn't report TCL errors in summary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83909 --- Comment #2 from lkrupp at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #1) > Note most folks run make check with -k also it won't even make a difference > there either. The patch seems to do the same thing for me when I run make with -k.
[Bug testsuite/83909] New: Make doesn't report TCL errors in summary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83909
Bug ID: 83909
Summary: Make doesn't report TCL errors in summary
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: lkrupp at gcc dot gnu.org
Target Milestone: ---
This test case in gfortran.dg:
! { dg-do compile }
xxx { dg-error "\\(CLASS)" }
triggers these messages when I run make -j 8 check-fortran:
ERROR: tcl error sourcing
/home/louis/gcc_trunk/gcc/testsuite/gfortran.dg/dg.exp.
ERROR: couldn't compile regular expression pattern: parentheses () not balanced
while executing
"regsub -all "(^|\n)(\[^\n\]+$line\[^\n\]*($pattern)\[^\n\]*\n?)+" $comp_output
"\n" comp_output"
(procedure "saved-dg-test" line 125)
invoked from within
"saved-dg-test /home/louis/gcc_trunk/gcc/testsuite/gfortran.dg/000bad.f90 { -O
} { -pedantic-errors}"
("eval" body line 1)
...
but the messages are buried in the output from Make, and there's no indication
in the test summary (# of passes, failures, etc) that there's been a problem.
The issue seems to be that runtest exits with an error but it runs in a
subprocess, it's followed by successful commands, and the error is never
propagated back to Make.
This patch terminates the action process tree with extreme prejudice and makes
it much more obvious that something has gone wrong:
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 256719)
+++ gcc/Makefile.in (working copy)
@@ -4078,7 +4078,7 @@ check-parallel-% : site.exp
TCL_LIBRARY=`cd .. ; cd $${srcdir}/../tcl/library ; ${PWD_COMMAND}`
; \
export TCL_LIBRARY ; \
fi ; \
- $(RUNTEST) --tool $(check_p_tool) $(RUNTESTFLAGS); \
+ $(RUNTEST) --tool $(check_p_tool) $(RUNTESTFLAGS) || kill 0; \
if [ -n "$$GCC_RUNTEST_PARALLELIZE_DIR" ] ; then \
touch $${rootme}/$(TESTSUITEDIR)/$(check_p_tool)-parallel/finished;
\
fi ; \
Make's final words look something like this:
make[2]: [Makefile:4083: check-parallel-gfortran] Terminated (ignored)
make[2]: [Makefile:4083: check-parallel-gfortran_6] Terminated (ignored)
got a TERM signal, terminated
I would not be surprised if there were a kinder, gentler way of dealing with
this.
[Bug fortran/82257] f951: Internal compiler error segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82257 lkrupp at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||lkrupp at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from lkrupp at gcc dot gnu.org --- Fixed in revision 256720.
[Bug fortran/82257] f951: Internal compiler error segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82257 --- Comment #2 from lkrupp at gcc dot gnu.org --- Author: lkrupp Date: Tue Jan 16 01:09:11 2018 New Revision: 256720 URL: https://gcc.gnu.org/viewcvs?rev=256720=gcc=rev Log: 2018-01-15 Louis Krupp <louis.kr...@zoho.com> PR fortran/82257 * interface.c (compare_rank): Don't try to retrieve CLASS_DATA from symbol marked unlimited polymorphic. * resolve.c (resolve_structure_cons): Likewise. * misc.c (gfc_typename): Don't dereference derived->components if it's NULL. 2018-01-15 Louis Krupp <louis.kr...@zoho.com> PR fortran/82257 * gfortran.dg/unlimited_polymorphic_28.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/unlimited_polymorphic_28.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/fortran/misc.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/83092] ICE in gfc_apply_init, at fortran/expr.c:4228
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83092 lkrupp at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||lkrupp at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from lkrupp at gcc dot gnu.org --- Fixed in revision 256011.
[Bug fortran/83092] ICE in gfc_apply_init, at fortran/expr.c:4228
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83092 --- Comment #3 from lkrupp at gcc dot gnu.org --- Author: lkrupp Date: Wed Dec 27 19:20:12 2017 New Revision: 256011 URL: https://gcc.gnu.org/viewcvs?rev=256011=gcc=rev Log: 2017_12_27 Louis Krupp <louis.kr...@zoho.com> PR fortran/83092 * expr.c (gfc_apply_init): Check that typespec has character type before using character length field. 2017_12_27 Louis Krupp <louis.kr...@zoho.com> PR fortran/83092 * gfortran.dg/init_char_with_nonchar_ctr.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/init_char_with_nonchar_ctr.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/55086] ICE with FORALL in allocate_temp_for_forall_nest_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55086 lkrupp at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||lkrupp at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from lkrupp at gcc dot gnu.org --- Fixed in revision 244601. Forall temporary handling has been improved, and a testing option, -ftest-forall-temp has been added.
[Bug fortran/50069] FORALL fails on a character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50069 lkrupp at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from lkrupp at gcc dot gnu.org --- Fixed in revision 244601. Offset adjustment for temporary arrays is fixed, or at least improved. Temporary arrays created for function return values are treated as variables and not as functions when passed as procedure arguments.
[Bug fortran/50069] FORALL fails on a character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50069 --- Comment #12 from lkrupp at gcc dot gnu.org --- Author: lkrupp Date: Wed Jan 18 21:41:48 2017 New Revision: 244601 URL: https://gcc.gnu.org/viewcvs?rev=244601=gcc=rev Log: 2017-01-18 Louis Krupp <louis.kr...@zoho.com> PR fortran/50069 PR fortran/55086 * gfortran.dg/pr50069_1.f90: New test. * gfortran.dg/pr50069_2.f90: New test. * gfortran.dg/pr55086_1.f90: New test. * gfortran.dg/pr55086_1_tfat.f90: New test. * gfortran.dg/pr55086_2.f90: New test. * gfortran.dg/pr55086_2_tfat.f90: New test. * gfortran.dg/pr55086_aliasing_dummy_4_tfat.f90: New test. 2017-01-18 Louis Krupp <louis.kr...@zoho.com> PR fortran/50069 PR fortran/55086 * trans-expr.c (gfc_conv_variable): Don't treat temporary variables as function arguments. * trans-stmt.c (forall_make_variable_temp, generate_loop_for_temp_to_lhs, gfc_trans_assign_need_temp, gfc_trans_forall_1): Don't adjust offset of forall temporary for array sections, make forall temporaries work for substring expressions, improve test coverage by adding -ftest-forall-temp option to request usage of temporary array in forall code. * lang.opt: Add -ftest-forall-temp option. * invoke.texi: Add -ftest-forall-temp option. Added: trunk/gcc/testsuite/gfortran.dg/pr50069_1.f90 trunk/gcc/testsuite/gfortran.dg/pr50069_2.f90 trunk/gcc/testsuite/gfortran.dg/pr55086_1.f90 trunk/gcc/testsuite/gfortran.dg/pr55086_1_tfat.f90 trunk/gcc/testsuite/gfortran.dg/pr55086_2.f90 trunk/gcc/testsuite/gfortran.dg/pr55086_2_tfat.f90 trunk/gcc/testsuite/gfortran.dg/pr55086_aliasing_dummy_4_tfat.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/55086] ICE with FORALL in allocate_temp_for_forall_nest_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55086 --- Comment #2 from lkrupp at gcc dot gnu.org --- Author: lkrupp Date: Wed Jan 18 21:41:48 2017 New Revision: 244601 URL: https://gcc.gnu.org/viewcvs?rev=244601=gcc=rev Log: 2017-01-18 Louis Krupp <louis.kr...@zoho.com> PR fortran/50069 PR fortran/55086 * gfortran.dg/pr50069_1.f90: New test. * gfortran.dg/pr50069_2.f90: New test. * gfortran.dg/pr55086_1.f90: New test. * gfortran.dg/pr55086_1_tfat.f90: New test. * gfortran.dg/pr55086_2.f90: New test. * gfortran.dg/pr55086_2_tfat.f90: New test. * gfortran.dg/pr55086_aliasing_dummy_4_tfat.f90: New test. 2017-01-18 Louis Krupp <louis.kr...@zoho.com> PR fortran/50069 PR fortran/55086 * trans-expr.c (gfc_conv_variable): Don't treat temporary variables as function arguments. * trans-stmt.c (forall_make_variable_temp, generate_loop_for_temp_to_lhs, gfc_trans_assign_need_temp, gfc_trans_forall_1): Don't adjust offset of forall temporary for array sections, make forall temporaries work for substring expressions, improve test coverage by adding -ftest-forall-temp option to request usage of temporary array in forall code. * lang.opt: Add -ftest-forall-temp option. * invoke.texi: Add -ftest-forall-temp option. Added: trunk/gcc/testsuite/gfortran.dg/pr50069_1.f90 trunk/gcc/testsuite/gfortran.dg/pr50069_2.f90 trunk/gcc/testsuite/gfortran.dg/pr55086_1.f90 trunk/gcc/testsuite/gfortran.dg/pr55086_1_tfat.f90 trunk/gcc/testsuite/gfortran.dg/pr55086_2.f90 trunk/gcc/testsuite/gfortran.dg/pr55086_2_tfat.f90 trunk/gcc/testsuite/gfortran.dg/pr55086_aliasing_dummy_4_tfat.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/79033] New: asan.c not compiling with make BOOT_CFLAGS='-O0' (or '-O1')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79033 Bug ID: 79033 Summary: asan.c not compiling with make BOOT_CFLAGS='-O0' (or '-O1') Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lkrupp at gcc dot gnu.org Target Milestone: --- When building with: make BOOT_CFLAGS='-O0' (or '-O1') This command: /home/louis/gcc_obj/./prev-gcc/xg++ -B/home/louis/gcc_obj/./prev-gcc/ -B/home/louis/gcc_inst/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/home/louis/gcc_obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/home/louis/gcc_obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/louis/gcc_obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/home/louis/gcc_obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/louis/gcc_trunk/libstdc++-v3/libsupc++ -L/home/louis/gcc_obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/louis/gcc_obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -O1 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc_trunk/gcc -I../../gcc_trunk/gcc/. -I../../gcc_trunk/gcc/../include -I../../gcc_trunk/gcc/../libcpp/include -I../../gcc_trunk/gcc/../libdecnumber -I../../gcc_trunk/gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc_trunk/gcc/../libbacktrace -o asan.o -MT asan.o -MMD -MP -MF ./.deps/asan.TPo ../../gcc_trunk/gcc/asan.c gets this error: ../../gcc_trunk/gcc/asan.c:1065:1: error: ‘%d’ directive output may be truncated writing between 1 and 11 bytes into a region of size 10 [-Werror=format-truncation=] asan_emit_stack_protection (rtx base, rtx pbase, unsigned int alignb, ^~ ../../gcc_trunk/gcc/asan.c:1065:1: note: using the range [1, -2147483648] for directive argument ../../gcc_trunk/gcc/asan.c:1163:26: note: format output between 22 and 32 bytes into a destination of size 30 use_after_return_class); The problem is with this code: 1071 char buf[30]; ... 1080 int use_after_return_class = -1; ... 1162 snprintf (buf, sizeof buf, "__asan_stack_malloc_%d", 1163 use_after_return_class); If use_after_return_class is in fact a negative 10-digit number, buf would overflow. With -O2, the compiler presumably knows more about the value of use_after_return_class, and asan.c compiles without errors. Changing buf to an array of length 31 makes the error go away, but I believe the length should be 32 to leave room for the terminating null byte.
[Bug fortran/69955] Memory leak with array constructor and derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69955 --- Comment #5 from lkrupp at gcc dot gnu.org --- Author: lkrupp Date: Fri Oct 7 02:24:40 2016 New Revision: 240851 URL: https://gcc.gnu.org/viewcvs?rev=240851=gcc=rev Log: 2016-10-06 Louis Krupp <louis.kr...@zoho.com> * gfortran.dg/pr69955.f90: New test. 2016-10-06 Louis Krupp <louis.kr...@zoho.com> PR fortran/69955 * trans-array.c (gfc_conv_expr_descriptor): Don't allocate components if it's not necessary. Added: trunk/gcc/testsuite/gfortran.dg/pr69955.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/69955] Memory leak with array constructor and derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69955 lkrupp at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||lkrupp at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from lkrupp at gcc dot gnu.org --- Fixed in revision 240851.
[Bug fortran/68800] Fortran FE produces many memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68800 Bug 68800 depends on bug 69955, which changed state. Bug 69955 Summary: Memory leak with array constructor and derived type https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69955 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/57910] ICE (segfault) with deferred-length strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57910 lkrupp at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||lkrupp at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from lkrupp at gcc dot gnu.org --- Fixed in revision 240850.
[Bug fortran/45170] [F2003] allocatable character lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Bug 45170 depends on bug 57910, which changed state. Bug 57910 Summary: ICE (segfault) with deferred-length strings https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57910 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/68241] [meta-bug] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 57910, which changed state. Bug 57910 Summary: ICE (segfault) with deferred-length strings https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57910 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/57910] ICE (segfault) with deferred-length strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57910 --- Comment #2 from lkrupp at gcc dot gnu.org --- Author: lkrupp Date: Fri Oct 7 02:02:13 2016 New Revision: 240850 URL: https://gcc.gnu.org/viewcvs?rev=240850=gcc=rev Log: 2016_10-06 Louis Krupp <louis.kr...@zoho.com> PR fortran/57910 * gfortran.dg/pr57910.f90: New test. 2016-10-05 Louis Krupp <louis.kr...@zoho.com> PR fortran/57910 * trans-expr.c (gfc_add_interface_mapping): Don't try to dereference call-by-value scalar argument Added: trunk/gcc/testsuite/gfortran.dg/pr57910.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/67524] ICE on using implicit character instead of implicit none etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67524 lkrupp at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||lkrupp at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from lkrupp at gcc dot gnu.org --- Fixed in revision 240797.
[Bug fortran/67524] ICE on using implicit character instead of implicit none etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67524 --- Comment #5 from lkrupp at gcc dot gnu.org --- Author: lkrupp Date: Wed Oct 5 18:00:30 2016 New Revision: 240797 URL: https://gcc.gnu.org/viewcvs?rev=240797=gcc=rev Log: 2016-10-05 Louis Krupp <louis.kr...@zoho.com> PR fortran/67524 * gfortran.dg/pr67524.f90: New test. 2016-10-05 Louis Krupp <louis.kr...@zoho.com> PR fortran/67524 * resolve.c (resolve_symbol): Don't apply default type rules to mixed-entry master created for function entry points. Added: trunk/gcc/testsuite/gfortran.dg/pr67524.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug c/77750] New: gcc build not working with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77750 Bug ID: 77750 Summary: gcc build not working with -O0 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: lkrupp at gcc dot gnu.org Target Milestone: --- Created attachment 39694 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39694=edit Possible patch (correctly formatted magic "fall through" comments) Within the last day or so, building GCC with this command: make BOOT_CFLAGS='-O0' CFLAGS_FOR_TARGET='-O0' CFLAGS_FOR_BUILD='-O0' started failing with these warnings, which are treated as errors: ../../gcc_trunk/gcc/combine.c: In function 'rtx_code simplify_compare_const(rtx_code, machine_mode, rtx, rtx_def**)': ../../gcc_trunk/gcc/combine.c:11364:7: error: this statement may fall through [-Werror=implicit-fallthrough] if (const_op > 0) ^~ ../../gcc_trunk/gcc/combine.c:11373:5: note: here case LE: ^~~~ ../../gcc_trunk/gcc/combine.c:11393:7: error: this statement may fall through [-Werror=implicit-fallthrough] if (const_op > 0) ^~ ../../gcc_trunk/gcc/combine.c:11402:5: note: here case GT: ^~~~ ../../gcc_trunk/gcc/combine.c: In function 'rtx_code simplify_comparison(rtx_code, rtx_def**, rtx_def**)': ../../gcc_trunk/gcc/combine.c:11924:4: error: this statement may fall through [-Werror=implicit-fallthrough] if (subreg_lowpart_p (op0) ^~ ../../gcc_trunk/gcc/combine.c:11932:2: note: here case ZERO_EXTEND: ^~~~ ../../gcc_trunk/gcc/combine.c:12340:6: error: this statement may fall through [-Werror=implicit-fallthrough] } ^ ../../gcc_trunk/gcc/combine.c:12343:2: note: here case LSHIFTRT: ^~~~ ../../gcc_trunk/gcc/fold-const.c: In function 'tree_node* extract_muldiv_1(tree, tree, tree_code, tree, bool*)': ../../gcc_trunk/gcc/fold-const.c:6276:7: error: this statement may fall through [-Werror=implicit-fallthrough] if ((code == TRUNC_MOD_EXPR || code == CEIL_MOD_EXPR ^~ ../../gcc_trunk/gcc/fold-const.c:6289:5: note: here case TRUNC_DIV_EXPR: case CEIL_DIV_EXPR: case FLOOR_DIV_EXPR: ^~~~ The build works without the '-O0' flags.
[Bug fortran/66107] ICE on missing parameter value for initialisation (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66107 lkrupp at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||lkrupp at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from lkrupp at gcc dot gnu.org --- Fixed in revision 240341. Code now checks to make sure that a parameter character array is initialized only with constant-length elements.
[Bug fortran/66107] ICE on missing parameter value for initialisation (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66107 --- Comment #2 from lkrupp at gcc dot gnu.org --- Author: lkrupp Date: Thu Sep 22 07:07:53 2016 New Revision: 240341 URL: https://gcc.gnu.org/viewcvs?rev=240341=gcc=rev Log: 2016-09-21 Louis Krupp <louis.kr...@zoho.com> PR fortran/66107 * gfortran.dg/pr66107.f90: New test. 2016-09-21 Louis Krupp <louis.kr...@zoho.com> PR fortran/66107 * decl.c (add_init_expr_to_sym): Catch variable character length in parameter array. Added: trunk/gcc/testsuite/gfortran.dg/pr66107.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61775 lkrupp at gcc dot gnu.org changed: What|Removed |Added CC||lkrupp at gcc dot gnu.org --- Comment #6 from lkrupp at gcc dot gnu.org --- I started looking at this until I read all of the comments and realized that someone had already come up with a patch, and one that is probably better and certainly simpler than whatever I would have done. It might be worth noting that the problem seems to come up when an array is passed to an intrinsic function that returns a scalar when its argument is a scalar and that returns an array when it's passed an array. In the sample program in the description, the intrinsic function is integer to real conversion. The following sample program reproduces that problem with a simple array instead of an implied do loop, and also with the square root function. Compiling this with -fbounds-check makes the program fail on the assignment statement: program assign_allocatable implicit none call s_int_real_cvt call s_sqrt contains subroutine s_int_real_cvt implicit none integer, parameter :: r(3) = [101, 102, 103] real, allocatable :: k(:) k = r if (any(k /= r)) call abort return end subroutine subroutine s_sqrt implicit none real, parameter :: r(5) = [1, 4, 9, 16, 25] real, allocatable :: a(:) a = sqrt(r) if (any(a /= [1, 2, 3, 4, 5])) call abort return end subroutine end program Array-value intrinsics like TRANSFER and PACK don't seem to trigger this problem.
[Bug fortran/68078] segfault with allocate and stat for derived types with default initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68078 lkrupp at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||lkrupp at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from lkrupp at gcc dot gnu.org --- Fixed in revison 240219. A newly allocated object (or array or pointer) with default initialization is now tested with the ALLOCATED() or ASSOCIATED() before initialization is done.
[Bug fortran/68078] segfault with allocate and stat for derived types with default initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68078 --- Comment #3 from lkrupp at gcc dot gnu.org --- Author: lkrupp Date: Sun Sep 18 05:52:23 2016 New Revision: 240219 URL: https://gcc.gnu.org/viewcvs?rev=240219=gcc=rev Log: 2016-09-17 Louis Krupp <louis.kr...@gmail.com> PR fortran/68078 * gfortran.dg/pr68078.f90: New test. * gfortran.dg/set_vm_limit.c: New, called by pr68078. 2016_09_17 Louis Krupp <louis.kr...@zoho.com> PR fortran/68078 * resolve.c (resolve_allocate_expr): Check that derived type pointer, object or array has been successfully allocated before initializing. Added: trunk/gcc/testsuite/gfortran.dg/pr68078.f90 trunk/gcc/testsuite/gfortran.dg/set_vm_limit.c Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/69963] ICE out of memory on displaced implicit character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69963 lkrupp at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||lkrupp at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from lkrupp at gcc dot gnu.org --- Fixed in revision 240168. The problem: In this example, subroutine s real x implicit character (a) a1 = 'z' end subroutine s the implicit statement is processed, the default typespec corresponding to the letter 'a' has its component charlen pointer set. When the implicit statement is then rejected as being out of order, all of the charlen structures it created are freed, default_type['a']->u.cl is left dangling, and bad things happen when 'a1' is parsed. This patch clears any default typespecs pointing to charlen structures that are about to be freed.
[Bug fortran/69963] ICE out of memory on displaced implicit character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69963 --- Comment #3 from lkrupp at gcc dot gnu.org --- Author: lkrupp Date: Thu Sep 15 23:54:40 2016 New Revision: 240168 URL: https://gcc.gnu.org/viewcvs?rev=240168=gcc=rev Log: 2016-09-15 Louis Krupp <louis.kr...@zoho.com> PR fortran/69963 * parse.c (reject_statement): Clear charlen pointers in implicit character typespecs before those charlen structures are freed. 2016-09-15 Louis Krupp <louis.kr...@zoho.com> PR fortran/69963 * gfortran.dg/misplaced_implicit_character.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/misplaced_implicit_character.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/69514] ICE with nested array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69514
--- Comment #6 from lkrupp at gcc dot gnu.org ---
Here's a test case for the paranoid among us:
! { dg-do run }
program p
implicit none
real , parameter :: arr(3) = [ real:: 2, 2.5, (1.5, 2.5) ]
real , parameter :: ari(3) = [ integer :: 2, 2.5, (1.5, 2.5) ]
real , parameter :: arc(3) = [ complex :: 2, 2.5, (1.5, 2.5) ]
integer, parameter :: air(3) = [ real:: 2, 2.5, (1.5, 2.5) ]
integer, parameter :: aii(3) = [ integer :: 2, 2.5, (1.5, 2.5) ]
integer, parameter :: aic(3) = [ complex :: 2, 2.5, (1.5, 2.5) ]
complex, parameter :: acr(3) = [ real:: 2, 2.5, (1.5, 2.5) ]
complex, parameter :: aci(3) = [ integer :: 2, 2.5, (1.5, 2.5) ]
complex, parameter :: acc(3) = [ complex :: 2, 2.5, (1.5, 2.5) ]
real , parameter :: mrr(3) = 4.5 * [ real:: 2, 2.5, (3.5, 4.0) ]
real , parameter :: mri(3) = 4.5 * [ integer :: 2, 2.5, (3.5, 4.0) ]
real , parameter :: mrc(3) = 4.5 * [ complex :: 2, 2.5, (3.5, 4.0) ]
integer, parameter :: mir(3) = 4 * [ real:: 2, 2.5, (3.5, 4.0) ]
integer, parameter :: mii(3) = 4 * [ integer :: 2, 2.5, (3.5, 4.0) ]
integer, parameter :: mic(3) = 4 * [ complex :: 2, 2.5, (3.5, 4.0) ]
complex, parameter :: mcr(3) = (4.5, 5.5) * [ real:: 2, 2.5, (3.5, 4.0) ]
complex, parameter :: mci(3) = (4.5, 5.5) * [ integer :: 2, 2.5, (3.5, 4.0) ]
complex, parameter :: mcc(3) = (4.5, 5.5) * [ complex :: 2, 2.5, (3.5, 4.0) ]
if (any(arr /= [2.00, 2.50, 1.50])) call abort
if (any(ari /= [2.00, 2.00, 1.00])) call abort
if (any(arc /= [2.00, 2.50, 1.50])) call abort
if (any(air /= [2, 2, 1])) call abort
if (any(aii /= [2, 2, 1])) call abort
if (any(aic /= [2, 2, 1])) call abort
if (any(acr /= [(2.00, 0.00), (2.50, 0.00), (1.50, 0.00)])) call abort
if (any(aci /= [(2.00, 0.00), (2.00, 0.00), (1.00, 0.00)])) call abort
if (any(acc /= [(2.00, 0.00), (2.50, 0.00), (1.50, 2.50)])) call abort
if (any(mrr /= [9.00, 11.25, 15.75])) call abort
if (any(mri /= [9.00, 9.00, 13.50])) call abort
if (any(mrc /= [9.00, 11.25, 15.75])) call abort
if (any(mir /= [8, 10, 14])) call abort
if (any(mii /= [8, 8, 12])) call abort
if (any(mic /= [8, 10, 14])) call abort
if (any(mcr /= [(9.00, 11.00), (11.25, 13.75), (15.75, 19.25)])) call abort
if (any(mci /= [(9.00, 11.00), ( 9.00, 11.00), (13.50, 16.50)])) call abort
if (any(mcc /= [(9.00, 11.00), (11.25, 13.75), (-6.25, 37.25)])) call abort
end program p
[Bug fortran/69514] ICE with nested array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69514
--- Comment #4 from lkrupp at gcc dot gnu.org ---
This patch is a kludge. I don't recommend it. But it does fix at least one of
the test cases, it passes the test suite, and it might point to a proper
solution:
Index: arith.c
===
--- arith.c (revision 239966)
+++ arith.c (working copy)
@@ -1326,7 +1326,21 @@ reduce_binary_ca (arith (*eval) (gfc_expr *, gfc_e
for (c = gfc_constructor_first (head); c; c = gfc_constructor_next (c))
{
if (c->expr->expr_type == EXPR_CONSTANT)
- rc = eval (op1, c->expr, );
+ {
+ /* The conversion *should* be done only if necessary. */
+ gfc_expr temp;
+
+ temp.expr_type = EXPR_OP;
+ gfc_clear_ts ();
+
+ temp.value.op.op = INTRINSIC_PLUS; /* Arbitrary */
+ temp.value.op.op1 = op1;
+ temp.value.op.op2 = c->expr;
+
+ gfc_type_convert_binary (,
+ warn_conversion || warn_conversion_extra);
+
+ rc = eval (op1, c->expr, );
+ }
else
rc = reduce_binary_ca (eval, op1, c->expr, );
[Bug fortran/69514] ICE with nested array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69514 lkrupp at gcc dot gnu.org changed: What|Removed |Added CC||lkrupp at gcc dot gnu.org --- Comment #3 from lkrupp at gcc dot gnu.org --- This slightly simpler program reproduces the problem at version 7.0: program p implicit none real, parameter :: w(1) = 3.0 * [ real :: 2 ] write(*,*) w end program p The problem seems to be that the constructed array is REAL (in ts.type field) and its element 2 is an INTEGER, but the 3.0 and 2 are multiplied (in gfc_arith_times) as if both were REAL.
[Bug fortran/77461] New: SUM intrinsic passed array of HUGE values triggers ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77461 Bug ID: 77461 Summary: SUM intrinsic passed array of HUGE values triggers ICE Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: lkrupp at gcc dot gnu.org Target Milestone: --- As seen on comp.lang.fortran, this file: double precision, parameter :: x = huge(1d0) print*, sum((/x,-x/)) print*, sum((/x,x,-x,-x/)) print*, sum((/x,-x,1d0/)) print*, sum((/1d0,x,-x/)) end triggers this ICE: Error: Arithmetic overflow at (1) f951: internal compiler error: Segmentation fault 0xba326f crash_signal ../../gcc_trunk/gcc/toplev.c:336 0x5de47b gfc_zero_size_array ../../gcc_trunk/gcc/fortran/arith.c:1657 0x5de47b reduce_binary0 ../../gcc_trunk/gcc/fortran/arith.c:1671 0x5de47b eval_intrinsic_f3 ../../gcc_trunk/gcc/fortran/arith.c:1720 0x6815eb simplify_transformation_to_scalar ../../gcc_trunk/gcc/fortran/simplify.c:491 0x61d2b1 do_simplify ../../gcc_trunk/gcc/fortran/intrinsic.c:4268 0x626f0b gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc_trunk/gcc/fortran/intrinsic.c:4617 0x66d72f resolve_unknown_f ../../gcc_trunk/gcc/fortran/resolve.c:2718 0x66d72f resolve_function ../../gcc_trunk/gcc/fortran/resolve.c:3020 0x66d72f gfc_resolve_expr(gfc_expr*) ../../gcc_trunk/gcc/fortran/resolve.c:6356 0x67217d gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc_trunk/gcc/fortran/resolve.c:10543 0x671ca3 gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc_trunk/gcc/fortran/resolve.c:9594 0x672356 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc_trunk/gcc/fortran/resolve.c:10533 0x6746e7 resolve_codes ../../gcc_trunk/gcc/fortran/resolve.c:15681 0x6747ae gfc_resolve(gfc_namespace*) ../../gcc_trunk/gcc/fortran/resolve.c:15716 0x65f754 resolve_all_program_units ../../gcc_trunk/gcc/fortran/parse.c:5875 0x65f754 gfc_parse_file() ../../gcc_trunk/gcc/fortran/parse.c:6127 0x6a1632 gfc_be_parse_file ../../gcc_trunk/gcc/fortran/f95-lang.c:198 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. gfortran -v reports: Target: x86_64-pc-linux-gnu Configured with: ../gcc_trunk/configure --disable-multilib \ --enable-languages=fortran Thread model: posix gcc version 7.0.0 20160902 (experimental) (GCC)
[Bug fortran/66056] ICEs and endless compilation for lonely labels/numbers in type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66056 lkrupp at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||lkrupp at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from lkrupp at gcc dot gnu.org --- Fixed in revision 229390. The problem: Statement labels within a type declaration are put in the statement label tree belonging to the type declaration's namespace's (instead of the current namespace). When the line is otherwise empty and an error is issued, gfc_free_st_label tries to delete the label from the label tree belonging to the current namespace and then frees the label structure, leaving an invalid statement label pointer in the type declaration's namespace's label tree. When that namespace is cleaned up, bad things can happen. The attached patch stores a namespace pointer in the statement label structure so that if a label is deleted early for some reason, it will be deleted from the proper namespace.
[Bug fortran/66056] ICEs and endless compilation for lonely labels/numbers in type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66056 --- Comment #6 from lkrupp at gcc dot gnu.org --- Author: lkrupp Date: Mon Oct 26 19:18:08 2015 New Revision: 229390 URL: https://gcc.gnu.org/viewcvs?rev=229390=gcc=rev Log: 2015-10-26 Louis Krupp <louis.kr...@zoho.com> PR fortran/66056 * fortran.h: Include namespace pointer in statement label structure. * symbol.c (gfc_get_st_label): Store pointer to namespace that owns the statement label tree in each label. (gfc_free_st_label): Use namespace owning statement label tree when deleting statement label. * io.c: Initialize format_asterisk with NULL namespace pointer. 2015-10-26 Louis Krupp <louis.kr...@zoho.com> PR fortran/66056 * gfortran.dg/empty_label_typedecl.f90: New test Added: trunk/gcc/testsuite/gfortran.dg/empty_label_typedecl.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/io.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/65766] gFortran Compiler SEGFAULTING on compiling simple program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65766 lkrupp at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||lkrupp at gcc dot gnu.org Resolution|--- |FIXED --- Comment #9 from lkrupp at gcc dot gnu.org --- Fixed on the trunk. Thanks for the report!
[Bug fortran/65766] gFortran Compiler SEGFAULTING on compiling simple program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65766 --- Comment #8 from lkrupp at gcc dot gnu.org --- Author: lkrupp Date: Tue Oct 6 23:47:18 2015 New Revision: 228551 URL: https://gcc.gnu.org/viewcvs?rev=228551=gcc=rev Log: 2015-10-06 Louis Krupp <louis.kr...@zoho.com> PR fortran/65766 * resolve.c (gfc_resolve_substring_charlen): For derived type, use typespec of string component when resolving substring length. 2015-10-06 Louis Krupp <louis.kr...@zoho.com> PR fortran/65766 * gfortran.dg/substr_alloc_string_comp_1.f90: New. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/62242] ICE in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62242
--- Comment #6 from lkrupp at gcc dot gnu.org ---
Author: lkrupp
Date: Fri Oct 2 04:03:34 2015
New Revision: 228368
URL: https://gcc.gnu.org/viewcvs?rev=228368=gcc=rev
Log:
2015-10-01 Louis Krupp <louis.kr...@zoho.com>
PR fortran/62242
PR fortran/52332
* trans-array.c
(store_backend_decl): Create new gfc_charlen instance if requested
(get_array_ctor_all_strlen): Call store_backend_decl requesting
new gfc_charlen
(trans_array_constructor): Call store_backend_decl requesting
new gfc_charlen if get_array_ctor_strlen was called
(gfc_add_loop_ss_code): Don't try to convert non-constant length
2015-10-01 Louis Krupp <louis.kr...@zoho.com>
PR fortran/62242
PR fortran/52332
* gfortran.dg/string_array_constructor_1.f90: New.
* gfortran.dg/string_array_constructor_2.f90: New.
* gfortran.dg/string_array_constructor_3.f90: New.
Added:
trunk/gcc/testsuite/gfortran.dg/string_array_constructor_1.f90 (with
props)
trunk/gcc/testsuite/gfortran.dg/string_array_constructor_2.f90 (with
props)
trunk/gcc/testsuite/gfortran.dg/string_array_constructor_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog
Propchange: trunk/gcc/testsuite/gfortran.dg/string_array_constructor_1.f90
('svn:executable' added)
Propchange: trunk/gcc/testsuite/gfortran.dg/string_array_constructor_2.f90
('svn:executable' added)
[Bug fortran/52332] Internal compiler error in in gfc_get_symbol_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52332
--- Comment #6 from lkrupp at gcc dot gnu.org ---
Author: lkrupp
Date: Fri Oct 2 04:03:34 2015
New Revision: 228368
URL: https://gcc.gnu.org/viewcvs?rev=228368=gcc=rev
Log:
2015-10-01 Louis Krupp <louis.kr...@zoho.com>
PR fortran/62242
PR fortran/52332
* trans-array.c
(store_backend_decl): Create new gfc_charlen instance if requested
(get_array_ctor_all_strlen): Call store_backend_decl requesting
new gfc_charlen
(trans_array_constructor): Call store_backend_decl requesting
new gfc_charlen if get_array_ctor_strlen was called
(gfc_add_loop_ss_code): Don't try to convert non-constant length
2015-10-01 Louis Krupp <louis.kr...@zoho.com>
PR fortran/62242
PR fortran/52332
* gfortran.dg/string_array_constructor_1.f90: New.
* gfortran.dg/string_array_constructor_2.f90: New.
* gfortran.dg/string_array_constructor_3.f90: New.
Added:
trunk/gcc/testsuite/gfortran.dg/string_array_constructor_1.f90 (with
props)
trunk/gcc/testsuite/gfortran.dg/string_array_constructor_2.f90 (with
props)
trunk/gcc/testsuite/gfortran.dg/string_array_constructor_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog
Propchange: trunk/gcc/testsuite/gfortran.dg/string_array_constructor_1.f90
('svn:executable' added)
Propchange: trunk/gcc/testsuite/gfortran.dg/string_array_constructor_2.f90
('svn:executable' added)
