[Bug fortran/66227] [5/6/7 Regression] [OOP] EXTENDS_TYPE_OF n returns wrong result for polymorphic variable allocated to extended type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66227 --- Comment #7 from janus at gcc dot gnu.org --- Author: janus Date: Thu Nov 17 07:52:24 2016 New Revision: 242535 URL: https://gcc.gnu.org/viewcvs?rev=242535&root=gcc&view=rev Log: 2016-11-17 Janus Weil PR fortran/66227 * simplify.c (gfc_simplify_extends_type_of): Fix missed optimization. Prevent over-simplification. Fix a comment. Add a comment. 2016-11-17 Janus Weil PR fortran/66227 * gfortran.dg/extends_type_of_3.f90: Fix and extend the test case. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/extends_type_of_3.f90
[Bug tree-optimization/78386] Optimization -O2 and higher cause math inconsistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 --- Comment #5 from Andrew Pinski --- Does -ffp-contract=off help?
[Bug fortran/78387] OpenMP segfault/stack size exceeded writing to internal file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78387 Thomas Koenig changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2016-11-17 Resolution|INVALID |--- Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #6 from Thomas Koenig --- OK, in that case, maybe I was hasty :-) The original test case has an external write, but the error does not depend on this. So, confirming.
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357 --- Comment #11 from Sebastian Huber --- Thanks for your kind help. Would it be possible to back port this to GCC 6 also?
[Bug target/78357] nios2 uses non-standard atomic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78357 --- Comment #10 from Chung-Lin Tang --- Author: cltang Date: Thu Nov 17 06:26:56 2016 New Revision: 242534 URL: https://gcc.gnu.org/viewcvs?rev=242534&root=gcc&view=rev Log: 2016-11-17 Chung-Lin Tang PR target/78357 * config/nios2/nios2.c (nios2_init_libfuncs): Remove TARGET_LINUX_ABI condition. (TARGET_INIT_LIBFUNCS): Delete definition and... * config/nios2/linux.h (TARGET_INIT_LIBFUNCS): ...move to here, add comments. Modified: trunk/gcc/ChangeLog trunk/gcc/config/nios2/linux.h trunk/gcc/config/nios2/nios2.c
[Bug c/78304] [7 Regression] -Wformat doesn't warn anymore for inttypes.h format string argument type mismatches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78304 --- Comment #2 from Marek Polacek --- Even though that with my patch we expansion_point_location_if_in_system_header the caret location, it still points to the location in the system header, so the diagnostics is suppressed.
[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 --- Comment #20 from Steve Kargl --- On Thu, Nov 17, 2016 at 01:44:45AM +, sgk at troutmask dot apl.washington.edu wrote: > > In the above, you are hitting an end-of-record. I would need > to go read the Standard to see what happens in this situation. > I suspect that this may be Standard conforming, but the variables > i and j are undefined and technically cannot be referenced until > the variables become defined. The acceptance of comma is a pox upon the world. The following should simply exit upon execution, instead prints ' 12' program foo open(unit=10, file='zxc') read(10, '(2I10)', eor=3, advance='no') i,j print *, i, j stop 3 continue end program foo where the file 'zxc' contains the line 1,2,3 gfortran is definitely doing the right thing with your original code. Using Fortran ability to report errors shows program foo integer k character(len=80) s, t s = '1,2,3' read(s, '(2I10)', err=3, iostat=k, iomsg=t) i,j print *, i, j stop 3 continue print *, k, trim(t) end program foo % gfc7 -o z c.f90 % ./z 5010 Bad value during integer read
[Bug c/78304] [7 Regression] -Wformat doesn't warn anymore for inttypes.h format string argument type mismatches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78304 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-17 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- It seems this has changed by r239253. The warning appears with -Wsystem-headers so it seemed like another instance of PR78000 / PR71613, except that my recent patch to fix this doesn't work. Will keep looking...
[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 --- Comment #19 from Steve Kargl --- On Thu, Nov 17, 2016 at 12:43:40AM +, kevin.b.beard at nasa dot gov wrote: > Many thanks to Jerry DeLisle [jvdeli...@charter.net]; he made us realize > that an internal record is now not treated the same as an external record! Ugh. It ought to be treated the same. > I didn't think of that. > > In the attached example, you see "1,2,3" read from a file with > > READ(1,'(2i10)') i,j > > DOES still work in gfortran 4.4.7, but This is a bug that needs to be fixed. > READ(1,'(a)') line > READ(line,'(2i10)') i,j > > does NOT. Standard conforming behavior as I have now pointed out in 3 posts. > If one parses the string appropriately and reads > it one part of a time, it does work: > > READ(line(1:1),'(i10)') i > READ(line(3:3),'(i10)') j In the above, you are hitting an end-of-record. I would need to go read the Standard to see what happens in this situation. I suspect that this may be Standard conforming, but the variables i and j are undefined and technically cannot be referenced until the variables become defined.
[Bug c/78285] error on duplicate switch label where a note should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78285 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c/78285] error on duplicate switch label where a note should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78285 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Thu Nov 17 01:23:19 2016 New Revision: 242532 URL: https://gcc.gnu.org/viewcvs?rev=242532&root=gcc&view=rev Log: PR c/78285 * c-common.c (c_add_case_label): Turn error_at calls into inform. * gcc.dg/switch-5.c: Turn several dg-errors into dg-messages. * g++.dg/ext/case-range2.C: Likewise. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/case-range2.C trunk/gcc/testsuite/gcc.dg/switch-5.c
[Bug fortran/78387] OpenMP segfault/stack size exceeded writing to internal file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78387 --- Comment #5 from Andrew Benson --- I couldn't find anything in the OpenMP specifications which addresses this issue - so presumably it's undefined behavior as far as OpenMP is concerned. But it seems that internal file writes were intended to be thread safe in gfortran - am I correct in understanding that? From what I can tell Intel fortran also makes internal file writes thread safe, for what it's worth.
[Bug other/78390] New: Bootstrap failure: match.pd: cannot determine type of operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
Bug ID: 78390
Summary: Bootstrap failure: match.pd: cannot determine type of
operand
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: vogt at linux dot vnet.ibm.com
CC: krebbel at gcc dot gnu.org
Target Milestone: ---
Host: s390x
Target: s390x
With the recent trunk I get a bootstrap failure on s390x. Configured with arch
zEC12, multilib, release checking, default languages on a zEC12 machine.
!!!
--
Bisecting failed to identify the commit that introduced the failure. The first
bad commit it found is trunk@242421:
MIPS/GCC/test: Implement `-mmicromips' option test
gcc/testsuite/
* gcc.target/mips/mips.exp (mips_option_tests): Add
`-mmicromips' array element.
which is mips exclusive and cannot be the cause of the problem.
The two commits before that only touch the testsuite, but bootstrapping them
hangs because genattrtab never finishes (using 100% cpu; terminated it after
three hours on one occation and after about 10 to 20 minutes on other
occasions). The next older commit builds fine. Further attempts to rebuild
trunk@242421 also end with genattrtab hanging. :-/
Another attempt without --multilib and --languages=c results in:
--
build/genmatch --gimple ~/src/gcc/gcc/match.pd \
> tmp-gimple-match.c
~/src/gcc/gcc/match.pd:93:3 warning: duplicate pattern
(plus:c @0 real_zerop@1)
^
~/src/gcc/gcc/match.pd:82:6 warning: previous pattern defined here
(op @0 integer_zerop)
^
(PLUS_EXPR @0 real_zerop@1)
~/src/gcc/gcc/match.pd:99:3 warning: duplicate pattern
(minus @0 real_zerop@1)
^
~/src/gcc/gcc/match.pd:82:6 warning: previous pattern defined here
(op @0 integer_zerop)
^
... (many more of these messages)
(CFN_BUILT_IN_LLFLOORL integer_valued_real_p@0)
GIMPLE decision tree has 1763 leafs, maximum depth 12 and a total number of
6840 nodes
~/src/gcc/gcc/match.pd:1615:44 error: cannot determine type of operand
(bit_and (convert (shift:shift_type (convert @3) @1)) { newmaskt;
})
^
[Bug other/78252] C++ demangler crashes with infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78252 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug other/78252] C++ demangler crashes with infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78252
--- Comment #2 from Nathan Sidwell ---
Created attachment 40062
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40062&action=edit
reduced source code
I've reduced the original source to the attached. This emits 4 function
symbols, 2 of which are instantiations of the forward function.
.type _Z3Foov, @function
.type _Z7forwardIZ3FoovEUlRT_E_EOS0_S1_, @function
.type _Z8indirectIRZ3FoovEUlRT_E_EvOS0_, @function
.type _Z7forwardIRZ3FoovEUlRT_E_EOS0_S1_, @function
the one directly called from Foo (_Z7forwardIZ3FoovEUlRT_E_EOS0_S1_) demangles
without crashing, but appears to be incorrect:
Foo()::{lambda()#1}&& ()
It's lost the 'forward' name. The other one
(_Z7forwardIRZ3FoovEUlRT_E_EOS0_S1_) causes infinite recursion. Here's a
snippet:
Foo()::{lambda(Foo()::{lambda(Foo()::{lambda(Foo()::{lambda(Foo
continuing ...
[Bug fortran/58001] Make it possible to silence "Extension: Tab character in format" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58001 kargl at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |7.0 --- Comment #15 from kargl at gcc dot gnu.org --- Fixed on trunk.
[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 --- Comment #17 from Dr. Kevin B. Beard --- Hi, Many thanks to Jerry DeLisle [jvdeli...@charter.net]; he made us realize that an internal record is now not treated the same as an external record! I didn't think of that. In the attached example, you see "1,2,3" read from a file with READ(1,'(2i10)') i,j DOES still work in gfortran 4.4.7, but READ(1,'(a)') line READ(line,'(2i10)') i,j does NOT. If one parses the string appropriately and reads it one part of a time, it does work: READ(line(1:1),'(i10)') i READ(line(3:3),'(i10)') j A workaround via an option would be great; better would be to have internal and external records READ the same way again. Thanks again for all your help, Kevin -- Dr. Kevin B. Beard, Lockheed Martin Corporation kevin.b.be...@nasa.gov 281-244-8534 room 548C, building 45, NASA Johnson Space Center US Mail: Kevin B. Beard, bldg 45, mail code Wyle/OPS/45, P.O.Box 58487, Houston, TX 77258 From: sgk at troutmask dot apl.washington.edu [gcc-bugzi...@gcc.gnu.org] Sent: Wednesday, November 16, 2016 1:25 PM To: Beard, Kevin B. (JSC-SD2)[WYLE LABORATORIES, INC.] Subject: [Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 --- Comment #16 from Steve Kargl --- On Wed, Nov 16, 2016 at 06:36:58PM +, kevin.b.beard at nasa dot gov wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 > > --- Comment #13 from Dr. Kevin B. Beard --- > Hi, > > Thanks for looking at this. I'm sorry to say I don't have access > to the official F77 standards, perhaps you could send me a copy > of the whole? google "F77 standard" https://www.fortran.com/F77_std/rjcnf0001.html https://gcc.gnu.org/wiki/GFortranStandards > The section you quoted doesn't seems too exclude the comma-terminated > behavior I've always seen, and it has been widely used > by many many programmers throughout the community over the years. I cited the entire relevant passage. Now, edited to its essences. 13.5.9.1 Integer Editing The Iw and Iw.m edit descriptors indicate that the field to be edited occupies w positions. On input, an Iw.m edit descriptor is treated identically to an Iw edit descriptor. In the input field, the character string must be in the form of an optionally signed integer constant, except for the interpretation of blanks (13.5.9, item (1)). In your code, you have character*80 s s= '1,2,3' READ(s,'(2i10)') i,j The format request a field width of 10 for 'i'. So, 10 positions in 's' are '1,2,3 ' (where I had to add a space because technically 's' does not have 10 positions). A signed integer constant does not contain 5 commas. > I've always been told and believed that a comma terminated a > numeric field; For list-directed input (i.e., FMT=*), yes, a comma is a value separator. > but w/o > access to the standards I can't point to the line that > says it must. You won't find a line. I cited the entire relevant text from Fortran 77 that applies to the above code. You either need to change the code to character*80 s ! 12345678901234567890 s= '1 2 ' READ(s,'(2i10)') i,j where '1' can appear anywhere within the first 10 positions, or character*80 s ! 12345678901234567890 s= '1,2,3' READ(s,*) i,j > What I'd like to see is that newer gfortran versions support > its previous (and every other FORTRAN compiler I've tested) > behavior. So, no bugs should ever be fixed? Have you filed bug reports with all the other vendors? I suspect that if you use an option with those vendors' compiler to request Standard conformance, you'll find that the code is invalid. If not, file a bug report with those vendors. > The flag "-std=legacy" does not restore the previous behavior, > and I've found no option in the newer gfortrans that does. That's because no one has implemented the patch to (un)fix gfortran to handle invalid code. jerryd has indicated that he'll look into the issue. I do find it ironic that you refuse to fix broken code, but expect those that strive to provide a quality tool like gfortran to break its conformance to the standard. -- You are receiving this mail because: You are on the CC list for the bug. You reported the bug. =
[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 --- Comment #18 from Dr. Kevin B. Beard --- Created attachment 40061 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40061&action=edit x2.dat
[Bug fortran/58001] Make it possible to silence "Extension: Tab character in format" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58001 --- Comment #14 from kargl at gcc dot gnu.org --- Author: kargl Date: Thu Nov 17 00:18:18 2016 New Revision: 242530 URL: https://gcc.gnu.org/viewcvs?rev=242530&root=gcc&view=rev Log: 2016-11-16 Steven G. Kargl PR fortran/58001 * io.c (next_char_not_space): Update handling of a 'tab' in a FORMAT. (format_lex): Adjust invocations of next_char_not_space(). 2016-11-16 Steven G. Kargl PR fortran/58001 * gfortran.dg/fmt_tab_1.f90: Adjust testcase. * gfortran.dg/fmt_tab_2.f90: Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/fmt_tab_1.f90 trunk/gcc/testsuite/gfortran.dg/fmt_tab_2.f90
[Bug libstdc++/70548] gdb pretty printers hang and spin cpu in gdb session.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70548
Henrique Andrade changed:
What|Removed |Added
CC||hcma at unscrambl dot com
--- Comment #1 from Henrique Andrade ---
I also have a reproducible example where this happens, using GNU gdb (GDB) Red
Hat Enterprise Linux 7.6.1-80.el7.
In my case it happens when a process starts a child process with gdb being
exec'ed as follows:
gdb -n -ex thread apply all bt full -batch -pid
When inspecting gdb's stack trace I see:
(gdb) where
#0 0x7ff8e6135a73 in __pread_nocancel () at
../sysdeps/unix/syscall-template.S:81
#1 0x004cdb0f in linux_xfer_partial ()
#2 0x004cea9e in linux_nat_xfer_partial ()
#3 0x005fc1dc in memory_xfer_partial_1 ()
#4 0x005fc78d in target_xfer_partial ()
#5 0x005fbdc9 in target_read ()
#6 0x005fbe50 in target_read_memory ()
#7 0x005973b2 in partial_memory_read ()
#8 0x0059a1a9 in read_string ()
#9 0x0059b64f in val_print_string ()
#10 0x005308d6 in apply_val_pretty_printer ()
#11 0x005981f5 in val_print ()
#12 0x005982c7 in common_val_print ()
#13 0x00530ab5 in apply_val_pretty_printer ()
#14 0x005981f5 in val_print ()
#15 0x005982c7 in common_val_print ()
#16 0x0059feda in print_variable_and_value ()
#17 0x005cc7c3 in do_print_variable_and_value ()
#18 0x005ce444 in iterate_over_block_local_vars ()
#19 0x005ce58c in print_frame_local_vars ()
#20 0x005ce7c0 in backtrace_command_1 ()
#21 0x005cec25 in backtrace_command ()
#22 0x00695b0a in execute_command ()
#23 0x005d398c in thread_apply_all_command ()
And strace shows it spinning as such:
ptrace(PTRACE_PEEKTEXT, 6820, 0x7f5a86d1f348, [0]) = 0
open("/proc/6820/mem", O_RDONLY)= 20
pread(20,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
33738576, 140026785690448) = 16596144
close(20) = 0
ptrace(PTRACE_PEEKTEXT, 6820, 0x7f5a86d1f350, [0]) = 0
open("/proc/6820/mem", O_RDONLY)= 20
pread(20,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
33738568, 140026785690456) = 16596136
close(20) = 0
ptrace(PTRACE_PEEKTEXT, 6820, 0x7f5a86d1f358, [0]) = 0
open("/proc/6820/mem", O_RDONLY)= 20
pread(20,
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
33738560, 140026785690464) = 16596128
close(20)
... (ad infinitum)
If I replace the invocation line to:
gdb -n -ex "disable pretty-printer" -ex "thread apply all bt fullä -batch -pid
The problem goes away and the gdb subprocess prints out the stack trace and
terminates as expected.
[Bug fortran/78387] OpenMP segfault/stack size exceeded writing to internal file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78387 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #4 from Jerry DeLisle --- (In reply to Jakub Jelinek from comment #3) > I thought they are supposed to be, at least that is what we had unit_lock, > u->lock etc. for. So has something in libgfortran changed so that it > doesn't properly lock the units anymore? Our intent was to maintain the correct locking. Recent changes for the DTIO patch may have broken something. We did touch a little there and thought we had it correct.
[Bug middle-end/78355] LRA generates unaligned accesses when SLOW_UNALIGNED_ACCESS is 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78355 --- Comment #7 from pipcet at gmail dot com --- (In reply to Eric Botcazou from comment #6) > > The analysis looks right for me. Although this code had a lot of troubles > > until it was stabilized and came to the current state. So the change might > > create some new failures but I hope it will not. > > OK, thanks, testing on arm-eabi didn't reveal any problem so I'm going to > install the change on the mainline. Thanks, that would be great! > But I think that we need a name to put in the ChangeLog, a simple email > address is not sufficient, so what name should I put? "Pip Cet", please. That's also the name I've filed the FSF copyright papers with, so I think it would be least confusing.
[Bug tree-optimization/78386] Optimization -O2 and higher cause math inconsistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 --- Comment #4 from joseph at codesourcery dot com --- On Wed, 16 Nov 2016, pinskia at gcc dot gnu.org wrote: > Most likely the use of fma. Which applies with current x86_64 just as it does with powerpc. It should be possible to reduce such an issue to a single function, with a specified argument for which that function returns different results with different optimization options. If it's an fma issue, using -ffp-contract=off should eliminate the difference between optimization levels.
[Bug c++/78373] [7 Regression] error: constant not recomputed when ADDR_EXPR changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78373 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|jakub at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug rtl-optimization/78378] [5/6 Regression] wrong code when combining shift + mult + zero_extend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78378 Jakub Jelinek changed: What|Removed |Added Summary|[5/6/7 Regression] wrong|[5/6 Regression] wrong code |code when combining shift + |when combining shift + mult |mult + zero_extend |+ zero_extend --- Comment #8 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug rtl-optimization/78378] [5/6/7 Regression] wrong code when combining shift + mult + zero_extend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78378
--- Comment #7 from Jakub Jelinek ---
Author: jakub
Date: Wed Nov 16 23:22:16 2016
New Revision: 242526
URL: https://gcc.gnu.org/viewcvs?rev=242526&root=gcc&view=rev
Log:
PR rtl-optimization/78378
* combine.c (make_extraction): Use force_to_mode for non-{REG,MEM}
inner only if pos is 0. Fix up formatting.
* gcc.c-torture/execute/pr78378.c: New test.
Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr78378.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/78325] [7 regression] r235825 causes gcc.target/mips/call-5.c, gcc.target/mips/call-6.c R_MIPS_JALR failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78325 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Alan Modra --- Fixed
[Bug rtl-optimization/70890] [7 regression] r235660 miscompiles stage2 compiler on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70890 --- Comment #10 from Alan Modra --- Author: amodra Date: Wed Nov 16 23:10:55 2016 New Revision: 242525 URL: https://gcc.gnu.org/viewcvs?rev=242525&root=gcc&view=rev Log: R_MIPS_JALR failures This is a fix for my PR70890 patch, which incorrectly removed all REG_EQUIV notes rather than just one regarding a reg that dies. PR rtl-optimization/78325 PR rtl-optimization/70890 * ira.c (combine_and_move_insns): Only remove REG_EQUIV notes for dead regno. Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c
[Bug rtl-optimization/78325] [7 regression] r235825 causes gcc.target/mips/call-5.c, gcc.target/mips/call-6.c R_MIPS_JALR failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78325 --- Comment #4 from Alan Modra --- Author: amodra Date: Wed Nov 16 23:10:55 2016 New Revision: 242525 URL: https://gcc.gnu.org/viewcvs?rev=242525&root=gcc&view=rev Log: R_MIPS_JALR failures This is a fix for my PR70890 patch, which incorrectly removed all REG_EQUIV notes rather than just one regarding a reg that dies. PR rtl-optimization/78325 PR rtl-optimization/70890 * ira.c (combine_and_move_insns): Only remove REG_EQUIV notes for dead regno. Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c
[Bug c++/78373] [7 Regression] error: constant not recomputed when ADDR_EXPR changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78373 --- Comment #4 from Jason Merrill --- Author: jason Date: Wed Nov 16 22:42:24 2016 New Revision: 242523 URL: https://gcc.gnu.org/viewcvs?rev=242523&root=gcc&view=rev Log: PR c++/78373 - ICE with TREE_CONSTANT reference * decl.c (cp_finish_decl): Don't set TREE_CONSTANT on a reference. * typeck2.c (store_init_value): Likewise. Added: trunk/gcc/testsuite/g++.dg/opt/pr78373.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/typeck2.c
[Bug libstdc++/78389] New: list::merge and list::sort are not exception safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78389 Bug ID: 78389 Summary: list::merge and list::sort are not exception safe Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- If a comparison throws in the middle of the loop, - list::merge will have spliced some elements over without updating the size of the lists. - list::sort will destroy any elements that have been transferred into the temporary lists. The former leaves the lists in an invariant-broken state. The latter is surprising at best.
[Bug tree-optimization/77848] Gimple if-conversion results in redundant comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77848 --- Comment #24 from Bill Schmidt --- The above commit doesn't yet solve the problem, but enables more outer-loop vectorization in preparation for the fix.
[Bug tree-optimization/77848] Gimple if-conversion results in redundant comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77848 --- Comment #23 from Bill Schmidt --- Author: wschmidt Date: Wed Nov 16 22:17:10 2016 New Revision: 242520 URL: https://gcc.gnu.org/viewcvs?rev=242520&root=gcc&view=rev Log: 2016-11-16 Bill Schmidt PR tree-optimization/77848 * tree-if-conv.c (version_loop_for_if_conversion): When versioning an outer loop, only save basic block aux information for the inner loop. (versionable_outer_loop_p): New function. (tree_if_conversion): Version the outer loop instead of the inner one if the pattern will be recognized for outer-loop vectorization. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-if-conv.c
[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66742 --- Comment #9 from TC --- The ugly fix in Comment #6 should be performant, if, well, ugly. It may be worth considering holding the nodes via a different type. There's no real reason why the temporary holders need to be a `list` or have a copy of the allocator as long as we make sure that everything in there is spliced back into *this when we exit sort() (by exception or normal return). Speaking of exceptions, merge() appears to have exception safety problems. I'll file a separate bug.
[Bug preprocessor/78324] Valgrind issues seen with gcc.dg/tree-ssa/builtin-sprintf-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78324
--- Comment #1 from David Malcolm ---
Root cause is that the substring loc code isn't set up to cope with
-ftrack-macro-expansion=0, and attempts to handle this location:
../../src/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-2.c:95:1: note:
RNG (0, 0, 0, "%hhi", i)
^~~
as the location of the literal, rather than:
RNG (0, 0, 0, "%hhi", i)
^~~~
On re-parsing to locate substring locations, it attempts to parse the 'R' as a
raw string, and so this code within cpp_interpret_string_1 fires:
if (*p == 'R')
{
const uchar *prefix;
/* Skip over 'R"'. */
p += 2;
prefix = p;
while (*p != '(')
p++;
and the issue happens in the "while" loop, as it erroneously walks through this
memory:
(gdb) p strs.m_vec.m_vecdata[0]
$20 = {len = 3, text = 0xc9bcca0 "RNG"}
trying to find the open parenthesis.
It looks like the substring_loc code needs to handle non-default values of
-ftrack-macro-expansion; am continuing to investigate.
[Bug libfortran/51119] MATMUL slow for large matrices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119 --- Comment #47 from Jerry DeLisle --- Author: jvdelisle Date: Wed Nov 16 21:54:25 2016 New Revision: 242518 URL: https://gcc.gnu.org/viewcvs?rev=242518&root=gcc&view=rev Log: 2016-11-16 Jerry DeLisle PR libgfortran/51119 * Makefile.am: Remove -fno-protect-parens -fstack-arrays. * Makefile.in: Regenerate. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in
[Bug middle-end/78355] LRA generates unaligned accesses when SLOW_UNALIGNED_ACCESS is 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78355 --- Comment #6 from Eric Botcazou --- > The analysis looks right for me. Although this code had a lot of troubles > until it was stabilized and came to the current state. So the change might > create some new failures but I hope it will not. OK, thanks, testing on arm-eabi didn't reveal any problem so I'm going to install the change on the mainline. But I think that we need a name to put in the ChangeLog, a simple email address is not sufficient, so what name should I put?
[Bug fortran/58001] Make it possible to silence "Extension: Tab character in format" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58001 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #13 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #11) > > What happened with patch in comment 9? > > PING! I've posted an updated patch that includes Manuel's comment #12.
[Bug c++/78388] New: Bogus "declaration shadows template parameter" error with parenthesized function-style casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78388
Bug ID: 78388
Summary: Bogus "declaration shadows template parameter" error
with parenthesized function-style casts
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
Reduced from http://stackoverflow.com/q/40637781/2756719:
template
void f()
{
(int((void(i), 1))) + 0;
}
prog.cc: In function 'void f()':
prog.cc:4:17: error: declaration of 'void i' shadows template parameter
(int((void(i), 1))) + 0;
^
prog.cc:1:10: note: template parameter 'i' declared here
template
^~~
Accepted by Clang and GCC 4.3.6 on Wandbox
(http://melpon.org/wandbox/permlink/BHMa6ZyICjlVpvZi); rejected since 4.4,
apparently.
[Bug tree-optimization/78386] Optimization -O2 and higher cause math inconsistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 Bill Schmidt changed: What|Removed |Added Target||powerpc64le-unknown-linux-g ||nu, x86_64-* Summary|Powerpc64le: optimization |Optimization -O2 and higher |-O2 and higher cause math |cause math inconsistency |inconsistency | --- Comment #3 from Bill Schmidt --- Breno and his team have indicated that this is a problem on x86_64 also, so changing the title and targets accordingly.
[Bug fortran/68778] [F03] Missing default initialization of finalized derived types type(C_PTR) component in subroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68778 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||janus at gcc dot gnu.org Known to work||7.0 Summary|Missing default |[F03] Missing default |initialization of finalized |initialization of finalized |derived types type(C_PTR) |derived types type(C_PTR) |component in subroutines|component in subroutines Known to fail||6.2.0 --- Comment #5 from janus at gcc dot gnu.org --- With gfortran 6.2, I get arbitrary values (T or F), changing in each run. With current trunk I always get F, so apparently this has been fixed on trunk. Can anyone confirm this?
[Bug c/78285] error on duplicate switch label where a note should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78285 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-11-16 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Should be rather trivial.
[Bug tree-optimization/78383] label as values ICE with C++ lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78383 --- Comment #2 from Marek Polacek --- I mean r160122 or r160124.
[Bug tree-optimization/78386] Powerpc64le: optimization -O2 and higher cause math inconsistency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 --- Comment #2 from Breno Leitao --- I did further tests with older versions, and the problem is also reproducible, so, this is not a regression. These are the versions I tested also: * gcc-5 (Debian 5.4.1-3) 5.4.1 20161019 * gcc-4 (Debian 4.9.4-2) 4.9.4
[Bug c++/68377] [c++17] unary right fold fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68377 Markus Trippelsdorf changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Markus Trippelsdorf --- It is probably caused by r228556.
[Bug fortran/78387] OpenMP segfault/stack size exceeded writing to internal file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78387 --- Comment #3 from Jakub Jelinek --- I thought they are supposed to be, at least that is what we had unit_lock, u->lock etc. for. So has something in libgfortran changed so that it doesn't properly lock the units anymore?
[Bug tree-optimization/78383] label as values ICE with C++ lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78383 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-16 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed. Started either with r160123 or r160124.
[Bug fortran/78387] OpenMP segfault/stack size exceeded writing to internal file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78387 --- Comment #2 from Andrew Benson --- OK - thanks. I hadn't realized that the internal I/O operations weren't threadsafe - I guess I've just been fortunate to avoid this with previous versions of gfortran. I'll update my code to use critical sections as necessary. Thanks for the fast response!
[Bug fortran/78387] OpenMP segfault/stack size exceeded writing to internal file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78387 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Thomas Koenig --- Hi Andrew, I/O operations are not thread safe. If you enclose them in !$omp critical, you will get the expected result: ig25@linux-fd1f:/tmp> cat omp.f90 program p double precision :: b b=0.1d0 !$omp parallel call s(b) !$omp end parallel contains subroutine s(a) implicit none double precision, intent(in) :: a character(len=10) :: f,c !$omp critical write (f,'(a5,i1,a1)') "(e10.",2,")" write (c,f) a write (0,*) trim(c) !$omp end critical return end subroutine s end program p ig25@linux-fd1f:/tmp> gfortran -fopenmp omp.f90 ig25@linux-fd1f:/tmp> ./a.out 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00
[Bug fortran/78387] New: OpenMP segfault/stack size exceeded writing to internal file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78387 Bug ID: 78387 Summary: OpenMP segfault/stack size exceeded writing to internal file Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com Target Milestone: --- The following code when run using OpenMP crashes with a "stack size exceeded" error (and, sometimes, a segfault) under gfortran 7.0.0 (r242500). This happens most times I run the code, but not every time. When compiled with gfortran 6.0.0 it runs successfully every time. program p double precision :: b b=0.1d0 !$omp parallel call s(b) !$omp end parallel contains subroutine s(a) implicit none double precision, intent(in) :: a character(len=10) :: f,c write (f,'(a5,i1,a1)') "(e10.",2,")" write (c,f) a write (0,*) trim(c) return end subroutine s end program p $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 7.0.0 20161116 (experimental) (GCC) $ gfortran t.F90 -g -fopenmp [abenson@mies v0.9.4]$ a.out 0.10E+00 0.10E+00 0.10E+00 0.10E+00 At line 12 of file t.F90 Internal Error: stash_internal_unit(): Stack Size Exceeded Error termination. Backtrace: 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 0.10E+00 #0 0x400a7b in s at /home/abenson/Galacticus/v0.9.4/t.F90:12 #1 0x400c53 in MAIN__._omp_fn.0 at /home/abenson/Galacticus/v0.9.4/t.F90:5 #2 0x7f786cbc955d in gomp_thread_start at ../../../gcc-trunk/libgomp/team.c:119 #3 0x7f786bdbdc39 in start_thread at /data001/abenson/Galacticus/Tools/glibc-2.12.1/nptl/pthread_create.c:301 #4 0x7f786c4c361c in ??? at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 #5 0x in ??? The frequency with which the code crashes increases as the number of OpenMP threads is increased (running with 2 threads it almost always runs successfully, with 4 threads it crashes on 1 run in 10-20, with 16 threads it crashes almost every time). The error is sometimes reported at line 12, sometimes at line 13 - but always the same "stack size exceeded" error.
[Bug bootstrap/72823] [7 Regression] r239175 causes build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72823 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/78386] Powerpc64le: optimization -O2 and higher cause math inconsitency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 --- Comment #1 from Andrew Pinski --- Most likely the use of fma.
[Bug c/78386] New: Powerpc64le: optimization -O2 and higher cause math inconsitency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386 Bug ID: 78386 Summary: Powerpc64le: optimization -O2 and higher cause math inconsitency Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: brenohl at br dot ibm.com Target Milestone: --- When compiling fdlibm with O2 or higher, the math results are different. I just write a simple example, invoking jcos() and invoking it several times. If I use -O1 and -O2, the results are different. I dug further and found that the problem happens when using the optimization '-expensive-optimizations'. As for example: $ gcc -I. -g -static -O1 -fexpensive-optimizations .. -o opt_call $ gcc -I. -g -static -O1 .. -o call $ ./opt_call cosine total sum is: 0.33853897900538427 $ ./call cosine total sum is: 0.33853897900536206 I wrote a testcase to show this problem, please find it at https://github.com/leitao/fdlibm/tree/master/gcc_bug: In order to reproduce the problem, just run: $ git clone https://github.com/leitao/fdlibm.git $ cd fdlibm/gcc_bug $ make $ ./call $ ./opt_call If any other detail is required, I can dig further: Machine Information: $ gcc --version gcc (Debian 6.2.0-13) 6.2.0 20161109 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ uname -a Linux testing 4.7.0-1-powerpc64le #1 SMP Debian 4.7.8-1 (2016-10-19) ppc64le GNU/Linux
[Bug bootstrap/72823] [7 Regression] r239175 causes build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72823 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Wed Nov 16 20:10:27 2016 New Revision: 242510 URL: https://gcc.gnu.org/viewcvs?rev=242510&root=gcc&view=rev Log: PR bootstrap/72823 * configure.ac (ENABLE_ASSERT_CHECKING): Define if gcc configure would define that macro. * configure: Regenerated. * config.in: Regenerated. Modified: trunk/libcpp/ChangeLog trunk/libcpp/config.in trunk/libcpp/configure trunk/libcpp/configure.ac
[Bug fortran/78299] [6 Regression] ICE in expand_omp_for_static_nochunk, at omp-low.c:9622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78299 Jakub Jelinek changed: What|Removed |Added Summary|[6/7 Regression] ICE in |[6 Regression] ICE in |expand_omp_for_static_nochu |expand_omp_for_static_nochu |nk, at omp-low.c:9622 |nk, at omp-low.c:9622 --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/61409] [5/6/7 regression] -Wmaybe-uninitialized false-positive with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61409 --- Comment #24 from Jeffrey A. Law --- OK. It's coming back to me now. And yes, Aldy, it was the edge 9->6 :-) So we have a PHI argument that references an uninitialized variable. There is a control predicate for that PHI argument, call it p. The use of the result of the PHI is also guarded. In this particular case the guard is !p. Thus there is no path through the CFG which uses the uninitialized variable. We ought to be able to look at the guard of the PHI argument as well as the guard for the use, at least that's the theory. Now onward to look at your patch...
[Bug fortran/69298] [OOP] Array finalisers seem to be given the wrong array when the array is a member variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69298
--- Comment #6 from janus at gcc dot gnu.org ---
Here is a further reduced test case, based on Dominique's variant in comment
#2, which (I think) runs into the same runtime-segfault when calling
stuff_1d_finaliser ...
module stuff_mod
implicit none
type :: stuff_type
integer :: junk
contains
final :: stuff_1d_finaliser
end type
contains
subroutine stuff_1d_finaliser( this )
type(stuff_type), intent(inout) :: this(:)
integer :: i
write( 6, '("Finalising stuff_type array")', advance='no' )
do i = lbound( this, 1 ), ubound( this, 1 )
write(6, '(" ", I0)', advance='no' ) this(i)%junk
end do
write( 6, '()' )
end subroutine
end module stuff_mod
program test
use stuff_mod
implicit none
integer, parameter :: n = 2
type test_type
type(stuff_type) :: things(n)
end type
call sub()
contains
subroutine sub()
type(test_type) :: tt
integer :: i
write( 6, '("Initialising")' )
do i = 1, n
tt%things(i) = stuff_type( i )
end do
write( 6, '("Done")' )
end subroutine
end
[Bug bootstrap/78385] New: Build of libgcc2 for target arm-eabi fails, if configuration --with-abi=apcs-gnu is used (in GCC-Build)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78385 Bug ID: 78385 Summary: Build of libgcc2 for target arm-eabi fails, if configuration --with-abi=apcs-gnu is used (in GCC-Build) Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: meisenmann@fh-salzburg.ac.at Target Milestone: --- If I build a Cross-GCC (on/with i686-w64-mingw32 fromm msys2) for --target=arm-eabi and use additionally the option --with-abi=apcs-gnu (to compile to OABI as default), the build of libgcc2 (a nearby last phase) will fail with: /x/GCC5/.temp/gcc/./gcc/xgcc -B/x/GCC5/.temp/gcc/./gcc/ -B/x/GCC5/V5.X.0/arm-eabi/bin/ -B/x/GCC5/V5.X.0/arm-eabi/lib/ -isystem /x/GCC5/V5.X.0/arm-eabi/include -isystem /x/GCC5/V5.X.0/arm-eabi/sys-include -Os @X:/GCC5/.temp/arm-eabi.opt -O2 -Os @X:/GCC5/.temp/arm-eabi.opt -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fno-inline -I. -I. -I../.././gcc -I../../../../src/gcc-5.X.0/libgcc -I../../../../src/gcc-5.X.0/libgcc/. -I../../../../src/gcc-5.X.0/libgcc/../gcc -I../../../../src/gcc-5.X.0/libgcc/../include-o _fixsfdi.o -MT _fixsfdi.o -MD -MP -MF _fixsfdi.dep -DL_fixsfdi -c ../../../../src/gcc-5.X.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS In file included from ../../../../src/gcc-5.X.0/libgcc/libgcc2.c:56:0: ../../../../src/gcc-5.X.0/libgcc/libgcc2.c: In function '__fixsfdi': x:\gcc5\src\gcc-5.x.0\libgcc\libgcc2.h:209:20: sorry, unimplemented: PCS variant #define __NDW(a,b) __ ## a ## di ## b ^ x:\gcc5\src\gcc-5.x.0\libgcc\libgcc2.h:282:19: note: in expansion of macro '__NDW' #define __fixsfdi __NDW(fixsf,) ^ ../../../../src/gcc-5.X.0/libgcc/libgcc2.c:1497:1: note: in expansion of macro '__fixsfdi' __fixsfdi (SFtype a) ^ make[2]: *** [Makefile:467: _fixsfdi.o] Error 1 Configuration of the previously build Cross-GCC: >arm-eabi-gcc -v Using built-in specs. COLLECT_GCC=\GCC5\V5.X.0\bin\arm-eabi-gcc COLLECT_LTO_WRAPPER=x:/gcc5/v5.x.0/bin/../libexec/gcc/arm-eabi/6.2.0/lto-wrapper.exe Target: arm-eabi Configured with: ../../src/gcc-5.X.0/configure --prefix=/x/GCC5/V5.X.0 --build=i686-w64-mingw32 --target=arm-eabi --disable-nls --disable-shared --disable-multilib --disable-threads --with-pkgversion='Built by ME, rev. 20161114' --enable-languages=c,c++ --with-gnu-as --with-gnu-ld --disable-win32-registry --with-arch=armv7-a --with-abi=apcs-gnu --with-float=softfp --with-fpu=vfpv3 --disable-tls --with-stabs --disable-__cxa_atexit --disable-decimal-float --disable-libgomp --disable-libquadmath --disable-libstdcxx-verbose --with-newlib --with-headers=../../src/newlib-2.3.0/newlib/libc/include --with-gxx-include-dir=/x/GCC5/V5.X.0/include/c++/5.X.0 --disable-libstdcxx-visibility --enable-fully-dynamic-string --with-gmp=C:/msys32/mingw32 --with-mpfr=C:/msys32/mingw32 --with-mpc=C:/msys32/mingw32 Thread model: single gcc version 6.2.0 (Built by ME, rev. 20161114) Additional information: Same failure occurs, If I build an GCC 5.4.0 (an same configuration). IMHO - It seems, that the -mabi-Option apcs-gnu (default) causes this issue on building of the function '__fixsfdi'; But no fail on e.g. __fixunsdfsi ... Best regards from Austria, Markus
[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 --- Comment #16 from Steve Kargl --- On Wed, Nov 16, 2016 at 06:36:58PM +, kevin.b.beard at nasa dot gov wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 > > --- Comment #13 from Dr. Kevin B. Beard --- > Hi, > > Thanks for looking at this. I'm sorry to say I don't have access > to the official F77 standards, perhaps you could send me a copy > of the whole? google "F77 standard" https://www.fortran.com/F77_std/rjcnf0001.html https://gcc.gnu.org/wiki/GFortranStandards > The section you quoted doesn't seems too exclude the comma-terminated > behavior I've always seen, and it has been widely used > by many many programmers throughout the community over the years. I cited the entire relevant passage. Now, edited to its essences. 13.5.9.1 Integer Editing The Iw and Iw.m edit descriptors indicate that the field to be edited occupies w positions. On input, an Iw.m edit descriptor is treated identically to an Iw edit descriptor. In the input field, the character string must be in the form of an optionally signed integer constant, except for the interpretation of blanks (13.5.9, item (1)). In your code, you have character*80 s s= '1,2,3' READ(s,'(2i10)') i,j The format request a field width of 10 for 'i'. So, 10 positions in 's' are '1,2,3 ' (where I had to add a space because technically 's' does not have 10 positions). A signed integer constant does not contain 5 commas. > I've always been told and believed that a comma terminated a > numeric field; For list-directed input (i.e., FMT=*), yes, a comma is a value separator. > but w/o > access to the standards I can't point to the line that > says it must. You won't find a line. I cited the entire relevant text from Fortran 77 that applies to the above code. You either need to change the code to character*80 s ! 12345678901234567890 s= '1 2 ' READ(s,'(2i10)') i,j where '1' can appear anywhere within the first 10 positions, or character*80 s ! 12345678901234567890 s= '1,2,3' READ(s,*) i,j > What I'd like to see is that newer gfortran versions support > its previous (and every other FORTRAN compiler I've tested) > behavior. So, no bugs should ever be fixed? Have you filed bug reports with all the other vendors? I suspect that if you use an option with those vendors' compiler to request Standard conformance, you'll find that the code is invalid. If not, file a bug report with those vendors. > The flag "-std=legacy" does not restore the previous behavior, > and I've found no option in the newer gfortrans that does. That's because no one has implemented the patch to (un)fix gfortran to handle invalid code. jerryd has indicated that he'll look into the issue. I do find it ironic that you refuse to fix broken code, but expect those that strive to provide a quality tool like gfortran to break its conformance to the standard.
[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 --- Comment #15 from Jerry DeLisle --- Well, on further investigation I see that we do have a flag in read_sf to signal a comma. It does not have this flag in read_sf_internal, So definitely does not work on strings. My bet is that when we/I split the function, way way back, I did not carry over the comma checks in order to get performance with internal units. I plan to test on a file and make sure this is working then I will see if I can do something on internal units that does not penalize too much.
[Bug rtl-optimization/78374] Segfault in cc1 (arm-eabi) on -O1 (or better)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78374 Markus Eisenmann changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Markus Eisenmann --- It seems to be a problem of the used msys2/mingw-environment: After updating the i686-w64-mingw32 GCC (an libraries ...) from 4.9.2 to 6.2.0 and re-build of my Cross-GCC this issue does not occurs / is fixed. Sorry; this is resolved (I.e, invalid/rejected).
[Bug tree-optimization/78384] New: [7 Regression] ICE: verify_flow_info failed (error: wrong outgoing edge flags at end of bb 15)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78384
Bug ID: 78384
Summary: [7 Regression] ICE: verify_flow_info failed (error:
wrong outgoing edge flags at end of bb 15)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-7.0.0-alpha20161113 snapshot ICEs when compiling the following reduced
snippet at -O3 or -Ofast:
void
a2 (int wv, int yg, int r9)
{
while (wv < 1)
{
int vn = r9 % 0;
while (yg < 1)
{
int lz;
for (r9 = 0; r9 < 17; ++r9)
{
}
it:
lz = (yg++ >= 0) ? 2 : 0;
wv = vn < lz;
}
}
goto it;
}
% x86_64-unknown-linux-gnu-gcc-7.0.0-alpha20161113 -O3 -w -c mohqqsmg.c
mohqqsmg.c: In function 'a2':
mohqqsmg.c:2:1: error: wrong outgoing edge flags at end of bb 15
a2 (int wv, int yg, int r9)
^~
mohqqsmg.c:2:1: internal compiler error: verify_flow_info failed
[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 --- Comment #14 from Dominique d'Humieres --- Try to find what you want in http://www.fortran.com/F77_std/rjcnf0001.html. Good luck!
[Bug rtl-optimization/78378] [5/6/7 Regression] wrong code when combining shift + mult + zero_extend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78378 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Created attachment 40059 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40059&action=edit gcc7-pr78378.patch Untested fix.
[Bug middle-end/61409] [5/6/7 regression] -Wmaybe-uninitialized false-positive with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61409 --- Comment #23 from Jeffrey A. Law --- Sorry, I can't remember if I meant 9->5 or 9->6 at this point :-) I need to refamiliarize myself with this stuff again to make sure I've got the basic concepts before reviewing the patch. But you can probably see now why I said there was some seriously powerful, but dense code in here that I'd like to be able to re-use elsewhere to prune other false positive may-be warnings.
[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 --- Comment #13 from Dr. Kevin B. Beard --- Hi, Thanks for looking at this. I'm sorry to say I don't have access to the official F77 standards, perhaps you could send me a copy of the whole? The section you quoted doesn't seems to to exclude the comma-terminated behavior I've always seen, and it has been widely used by many many programmers throughout the community over the years. I've always been told and believed that a comma terminated a numeric field; but w/o access to the standards I can't point to the line that says it must. What I'd like to see is that is that newer gfortran versions support its previous (and every other FORTRAN compiler I've tested) behavior. The flag "-std=legacy" does not restore the previous behavior, and I've found no option in the newer gfortrans that does. $> cat x1.f character*80 s s= '1,2,3' READ(s,'(2i10)') i,j write(6,'(2i10)') i,j end $> gfortran --version GNU Fortran (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16) Copyright (C) 2010 Free Software Foundation, Inc. $> gfortran -std=legacy -o x1 x1.f $> ./x1 At line 3 of file x1.f Fortran runtime error: Bad value during integer read vs: $> gfortran ---version GNU Fortran (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55) Copyright (C) 2007 Free Software Foundation, Inc. $> gfortran -o x1 x1.f $> ./x1 1 2 $> g77 --version GNU Fortran (GCC) 3.4.6 20060404 (Red Hat 3.4.6-4.1) Copyright (C) 2006 Free Software Foundation, Inc. $> g77 -o x1_g77 x1.f $> ./x1_g77 1 2 $> ifort --version ifort (IFORT) 16.0.3 20160415 Copyright (C) 1985-2016 Intel Corporation. All rights reserved. $> ifort -o x1_ifort x1.f $> ./x1_ifort 1 2 What I'd like to see is to restore gfortran's previous behavior that it's had since it came out. Thanks again for looking into this, Kevin -- Dr. Kevin B. Beard, Lockheed Martin Corporation kevin.b.be...@nasa.gov 281-244-8534 room 548C, building 45, NASA Johnson Space Center US Mail: Kevin B. Beard, bldg 45, mail code Wyle/OPS/45, P.O.Box 58487, Houston, TX 77258 From: sgk at troutmask dot apl.washington.edu [gcc-bugzi...@gcc.gnu.org] Sent: Tuesday, November 15, 2016 6:06 PM To: Beard, Kevin B. (JSC-SD2)[WYLE LABORATORIES, INC.] Subject: [Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 --- Comment #7 from Steve Kargl --- On Tue, Nov 15, 2016 at 10:51:41PM +, kevin.b.beard at nasa dot gov wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 > > --- Comment #5 from Dr. Kevin B. Beard --- > I've always understood that a comma will terminate a FORTRAN field - for > example: > > https://docs.oracle.com/cd/E19957-01/805-4939/z4000743a36d/index.html > > Am I misunderstanding the F77 standard? Yes. If you read the text at the above URL, you find "The I/O system is just being more lenient than described in the FORTRAN Standard." The Fortran 77 standard contains 13.2.1 Edit Descriptors An edit descriptor is either a repeatable edit descriptor or a nonrepeatable edit descriptor. The forms of a repeatable edit descriptor are: Iw Iw.m ... where: I, F, E, D, G, L, and A indicate the manner of editing w and e are nonzero, unsigned, integer constants d and m are unsigned integer constants 13.5 Editing A field is a part of a record that is read on input or written on output when format control processes one I, F, E, D, G, L, A, H, or apostrophe edit descriptor. The field width is the size in characters of the field. 13.5.9 Numeric Editing The I, F, E, D, and G edit descriptors are used to specify input/output of integer, real, double precision, and complex data. The following general rules apply: (1) On input, leading blanks are not significant. The interpretation of blanks, other than leading blanks, is determined by a combination of any BLANK= specifier and any BN or BZ blank control that is currently in effect for the unit (13.5.8). Plus signs may be omitted. A field of all blanks is considered to be zero. (2) On input, with F, E, D, and G editing, a decimal point appearing in the input field overrides the portion of an edit descriptor that specifies the decimal point location. The input field may have more digits than the processor uses to approximate the value of the datum. (3) On output, ... (4) On output, ... (5) On output, ... 13.5.9.1 Integer Editing The Iw and Iw.m edit descriptors indicate that the field to be edited occupies w positions. The specified input/output list item must be of type integer. On input, the specified list item will become defined with an integer datum. On output, the specified list item must be defined with an integer datum. On input, an Iw.m edit descriptor is treated identically to an Iw edit
[Bug preprocessor/78324] Valgrind issues seen with gcc.dg/tree-ssa/builtin-sprintf-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78324 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org
[Bug rtl-optimization/50217] combine pass generated wrong code for unsigned char comparison on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50217 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- No feedback in over 4 years closing.
[Bug fortran/78299] [6/7 Regression] ICE in expand_omp_for_static_nochunk, at omp-low.c:9622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78299 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Wed Nov 16 18:19:09 2016 New Revision: 242507 URL: https://gcc.gnu.org/viewcvs?rev=242507&root=gcc&view=rev Log: PR fortran/78299 * omp-low.c (expand_omp_for_static_nochunk): Don't assert that loop->header == body_bb if broken_loop. * gfortran.dg/gomp/pr78299.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr78299.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog
[Bug libfortran/51119] MATMUL slow for large matrices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119 --- Comment #46 from Thomas Koenig --- (In reply to Jerry DeLisle from comment #44) > Yes I am aware of these. I was willing to live with them, but if it is a > problem, we can remove those options easy enough. I think it is no big deal, but on the whole I would prefer not to have the warnings. So, please go ahead and remove these options. The patch to do so is either pre-approved or obvious and simple; it is your choice :-)
[Bug rtl-optimization/78378] [5/6/7 Regression] wrong code when combining shift + mult + zero_extend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78378 --- Comment #5 from Jakub Jelinek --- Scratch that, I've missed there the 8 SUBREG_BYTE. That one is fine. What is wrong is combine_simplify_rtx turning (set (reg:SI 99 [ x ]) (and:SI (subreg:SI (truncate:HI (lshiftrt:TI (mult:TI (zero_extend:TI (reg:DI 96)) (zero_extend:TI (reg:DI 98))) (const_int 64 [0x40]))) 0) (const_int 65535 [0x]))) into (set (reg:SI 99 [ x ]) (zero_extend:SI (mult:HI (subreg:HI (reg:DI 96) 0) (subreg:HI (reg:DI 98) 0
[Bug fortran/41539] [OOP] Calling function which takes CLASS: Rank comparison does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41539 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug fortran/44131] [OOP] Using polymorphism in modules unware of derived types fails at run-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44131 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Target Milestone|--- |4.6.0
[Bug fortran/44863] [OOP] Fortran runtime error: internal error: bad hash value in dynamic dispatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44863 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug fortran/44864] [OOP] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44864 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug fortran/45795] [OOP] ICE in in gfc_add_component_ref plus bogus error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45795 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Target Milestone|--- |4.6.0
[Bug fortran/49961] [OOP] type-bound function can not return a pointer of a array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49961 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug fortran/51791] [OOP] Failure to resolve typebound function call with base object in parentheses.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51791 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Target Milestone|--- |4.7.0
[Bug fortran/51207] [OOP] Mark __def_init_... as FL_PARAMETER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51207 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug fortran/51943] [OOP] ICE in conv_function_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51943 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Target Milestone|--- |4.7.0
[Bug fortran/55935] [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55935 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug fortran/56929] [OOP] [F08] ICE on dummy argument child class with coarray inside parent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56929 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug fortran/56845] [OOP] _vptr not set to declared type for CLASS + SAVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56845 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug fortran/57145] [OOP] Faulty "Actual argument must be polymorphic" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57145 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Target Milestone|--- |4.8.0
[Bug fortran/57456] [OOP] CLASS + CHARACTER ALLOCATE with typespec: For arrays, the typespec is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57456 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Target Milestone|--- |5.0
[Bug fortran/57922] [OOP] Memory leak with allocatable polymorphics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57922 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug tree-optimization/78383] New: label as values ICE with C++ lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78383
Bug ID: 78383
Summary: label as values ICE with C++ lambda
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: SztfG at yandex dot ru
Target Milestone: ---
testcase:
int main()
{
auto f = [](void* ptr) { goto *ptr; };
f(&&label);
label:
return 0;
}
$ g++ -std=c++11 -O2 test.cpp
test.cpp: In function ‘main()::’:
test.cpp:3:23: internal compiler error: Segmentation fault
auto f = [](void* ptr) { goto *ptr; };
^
[Bug fortran/58947] [OOP] ICE on select type with non-polymorphic selector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58947 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.1
[Bug fortran/58658] [OOP] Pointer assignment to allocatable unlimited polymorphic accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58658 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Target Milestone|--- |4.9.0
[Bug fortran/60834] [OOP] ICE with ASSOCIATE construct (gimplify_var_or_parm_decl, at gimplify.c:1721)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60834 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Target Milestone|--- |4.9.1
[Bug fortran/60255] [OOP] Deferred character length variable at (1) cannot yet be associated with unlimited polymorphic entities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60255 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.3
[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug fortran/60550] [OOP] ICE on factory design pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60550 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.1
[Bug fortran/63553] [OOP] Wrong code when assigning a CLASS to a TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63553 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Target Milestone|--- |5.0
[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 nsz at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |7.0 Known to fail||5.4.0, 6.2.0
[Bug fortran/64589] [OOP] Linking error due to undefined integer symbol with unlimited polymorphism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64589 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug fortran/64674] [OOP] ICE in ASSOCIATE with class array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64674 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug fortran/67091] [OOP] Bad result for type-bound procedures returning pointers to the intrinsic function ASSOCIATED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67091 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 --- Comment #3 from nsz at gcc dot gnu.org --- Author: nsz Date: Wed Nov 16 17:27:04 2016 New Revision: 242505 URL: https://gcc.gnu.org/viewcvs?rev=242505&root=gcc&view=rev Log: [PR libgfortran/78314] Fix ieee_support_halting ieee_support_halting only checked the availability of status flags, not trapping support. On some targets the later can only be checked at runtime: feenableexcept reports if enabling traps failed. So check trapping support by enabling/disabling it. Updated the test that enabled trapping to check if it is supported. gcc/testsuite/ PR libgfortran/78314 * gfortran.dg/ieee/ieee_6.f90: Use ieee_support_halting. libgfortran/ PR libgfortran/78314 * config/fpu-glibc.h (support_fpu_trap): Use feenableexcept. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/ieee/ieee_6.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/config/fpu-glibc.h
[Bug fortran/64209] [OOP] runtime segfault with CLASS(*), INTENT(OUT) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64209 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
