[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 99936, which changed state. Bug 99936 Summary: [modules] FAIL: g++.dg/modules/xtreme-header* on Darwin https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227 Bug 99227 depends on bug 99936, which changed state. Bug 99936 Summary: [modules] FAIL: g++.dg/modules/xtreme-header* on Darwin https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug c++/99936] [modules] FAIL: g++.dg/modules/xtreme-header* on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936 Dominique d'Humieres changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #10 from Dominique d'Humieres --- I am closing the PR as FIXED. If there is any objection, please reopen it.
[Bug c++/99936] [modules] FAIL: g++.dg/modules/xtreme-header* on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #8 from Dominique d'Humieres --- The failures have disappeared between r12-7172 and r12-7200.
[Bug fortran/103434] Pointer subobject does not show to correct memory location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103434 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-11-26 Status|UNCONFIRMED |WAITING --- Comment #1 from Dominique d'Humieres --- This seems to have been fixed on GCC12 and at least since r11-9157, bur not for r10-10223.
[Bug fortran/103045] False report substring out of bounds with -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103045 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-11-02 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- This has been fixed in r10-10223, 11 and 12.
[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992 Dominique d'Humieres changed: What|Removed |Added CC||gccbug at duemmels dot de --- Comment #27 from Dominique d'Humieres --- *** Bug 103043 has been marked as a duplicate of this bug. ***
[Bug fortran/103043] gfortran can not write to files (macOS Monterey GCC 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103043 Dominique d'Humieres changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Dominique d'Humieres --- Dup. *** This bug has been marked as a duplicate of bug 102992 ***
[Bug fortran/67542] ICE in gfc_emit_parameter_debug_info, at fortran/trans-decl.c:4947 and :4945
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67542 --- Comment #13 from Dominique d'Humieres --- Duplicate of pr102685, fixed by r12-4452?
[Bug fortran/99183] [9/10/11 Regression] Incompatible Runtime types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99183 --- Comment #4 from Dominique d'Humieres --- > This seems to have been fixed between r12-4097 and r12-4638. Duplicate of pr102745, fixed by r12-4464?
[Bug fortran/100970] ICE in output_constructor_regular_field, at varasm.c:5514
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100970 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #2 from Dominique d'Humieres --- This seems to have been fixed before r12-4638.
[Bug fortran/99183] [9/10/11 Regression] Incompatible Runtime types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99183 Dominique d'Humieres changed: What|Removed |Added Summary|Incompatible Runtime types |[9/10/11 Regression] ||Incompatible Runtime types --- Comment #3 from Dominique d'Humieres --- This seems to have been fixed between r12-4097 and r12-4638.
[Bug fortran/92701] ICE assigning to assumed rank derived type component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92701 --- Comment #3 from Dominique d'Humieres --- This seems to have been fixed between r11-4933 and r11-6947 and back ported to gcc10.
[Bug fortran/67542] ICE in gfc_emit_parameter_debug_info, at fortran/trans-decl.c:4947 and :4945
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67542 --- Comment #12 from Dominique d'Humieres --- As for r12-4638 the tests are now rejected whit Error: The shape of component 'c' in the structure constructor at (1) differs from the shape of the declared component for dimension 1 (2/1) So this old PR could probably be closed as FIXED.
[Bug fortran/102901] ICE (segfault) when compiling pdt_13.f03 with -fcheck=all in gfc_check_pdt_dummy -> structure_alloc_comps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102901 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-10-23 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug fortran/102900] ICE via gfc_class_data_get with alloc_comp_class_4.f03 or proc_ptr_52.f90 using -fcheck=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102900 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-23 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Th error for gfc_class_data_get and alloc_comp_class_4.f03 is: ../../work/gcc/fortran/trans-expr.c:230:7: runtime error: member access within null pointer of type 'union tree_node' For the ICE is internal compiler error: tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_class_data_get, at fortran/trans-expr.c:232
[Bug fortran/102903] Invalid gfortran.dg testcases or wrong-code with -fcheck=all -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102903 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-10-23 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed. The test pr17143.f90 relies on wrapping on overflow, so it's probably a WONTFIX. Reduced test for power_8.f90: integer(1) :: j j = 7 print *, (-2_1) ** j print *, (-512_8) ** j end There are no runtime errors if I replace j with 7.
[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342 --- Comment #7 from Dominique d'Humieres --- > Has this bug been fully fixed now, so that we can close it? It seems so.
[Bug fortran/102862] CLASS(*) – various issues, esp. with assumed-rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102862 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-22 --- Comment #1 from Dominique d'Humieres --- Confirmed from gfortan 10 up to master.
[Bug fortran/100916] Bind(c): CFI_type_other unimplemented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100916 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-22 Ever confirmed|0 |1
[Bug fortran/100907] Bind(c): failure handling wide character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100907 --- Comment #11 from Dominique d'Humieres --- In both case I get FAIL! chrcmp: 66 != 65281 FAIL! chrcmp: 66 != 65281 FAIL! chrcmp: 67 != 65282 FAIL! chrcmp: 68 != 65283 FAIL! chrcmp: 69 != 65284 FAIL! chrcmp: 70 != 65285 FAIL! chrcmp: 71 != 65286 FAIL! chrcmp: 72 != 65287 FAIL! chrcmp: 73 != 65288 FAIL! chrcmp: 74 != 65289 FAIL! chrcmp: 75 != 65290 FAIL! chrcmp: 0 != 65291 FAIL! char: 75 != 11 Assertion failed: (c_vrfy_character (auxp)), function check_tk, file pr100907_db.c, line 215. Program received signal SIGABRT: Process abort signal.
[Bug fortran/102503] ICE in gfc_conv_array_bound, at fortran/trans-types.c:1224
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102503 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-10-22 --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug testsuite/102859] [OpenMP] Missing testsuite coverage for Fortran task reductions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102859 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-21 --- Comment #1 from Dominique d'Humieres --- Please do not import PR88707 unless it is fixed.
[Bug fortran/102885] New: [12 Regression] ICE when compiling gfortran.dg/bind_c_char_10.f90 with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102885 Bug ID: 102885 Summary: [12 Regression] ICE when compiling gfortran.dg/bind_c_char_10.f90 with -flto Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: burnus at gcc dot gnu.org, hubicka at gcc dot gnu.org, iains at gcc dot gnu.org, sandra at gcc dot gnu.org Target Milestone: --- The test gfortran.dg/bind_c_char_10.f90 ICE when compiled with -flto: lto1: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See <https://gcc.gnu.org/bugs/> for instructions. lto-wrapper: fatal error: gfc returned 1 exit status compilation terminated. collect2: fatal error: lto-wrapper returned 1 exit status compilation terminated. Reduced test: module m use iso_c_binding, only: c_char implicit none (type, external) contains ! Assumed-shape array, nonallocatable/nonpointer subroutine ar3 (xn, n) bind(C) integer :: n character(len=n) :: xn(..) if (size(xn) /= 6) stop if (len(xn) /= 5) stop select rank(xn) rank(1) xn = ['FDGhf', & 'hdrhg', & 'fDgFl', & 'DFHs3', & '4a54G', & 'hSs6k'] rank default stop end select end end program main use m implicit none (type, external) character(kind=c_char, len=5) :: str5a6(6) ! assumed rank - with array descriptor str5a6 = ['DDGhf', & 'hdrh$', & 'fDGSl', & 'DFHs3', & '43grG', & 'hFG$k'] call ar3 (str5a6, 5) end All the other tests compile with -flto.
[Bug fortran/102787] ICE in new test case gfortran.dg/reshape_shape_2.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102787 Dominique d'Humieres changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug fortran/102787] ICE in new test case gfortran.dg/reshape_shape_2.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102787 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-10-16 Status|UNCONFIRMED |ASSIGNED --- Comment #4 from Dominique d'Humieres --- Confirmed on Darwin too.
[Bug c++/99936] [modules] FAIL: g++.dg/modules/xtreme-header* on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936 --- Comment #2 from Dominique d'Humieres --- New failures between r12-4031 and r12-4090: FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (internal compiler error) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2a (internal compiler error) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2a (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2b (internal compiler error) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2b (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi (gcm.cache/\$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm) FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi (gcm.cache/\$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm) FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi (gcm.cache/\$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm) FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++2b (test for excess errors)
[Bug fortran/102366] [10/11/12 Regression] large arrays no longer become static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 --- Comment #10 from Dominique d'Humieres --- > Seems it changed with r12-3129-gf95946afd160e2a1f4beac4ee5e6d5633307f39a The problem is gone if I revert r12-3129.
[Bug fortran/102366] [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 --- Comment #3 from Dominique d'Humieres --- > What is your stack size? 65532 kbytes > Does it help if you declare a SAVEd? The illegal instruction is gone.
[Bug fortran/102366] New: [10/11/12 Regression] Illegal instruction with large arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102366 Bug ID: 102366 Summary: [10/11/12 Regression] Illegal instruction with large arrays Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr Target Milestone: --- The following test REAL(KIND=4) :: a(16776325), s a=1.0_8 END gives at run time Illegal instruction a(16775301) to a(16776324) gives Segmentation fault and below a(16776323) the code run as expected. This occurred between r12-3046 (OK) and r12-3430 and r10-10049 (OK) and r10-10122. It also affects r11-8981. Note that REAL(KIND=4) :: a(16776325), s a(16776325)=1.0_8 END compiles and runs witout problem.
[Bug debug/101283] Several tests fail on Darwin with -gctf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-07-01 Ever confirmed|0 |1
[Bug debug/101283] New: Severaal test fail on Darwin with -gctf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283 Bug ID: 101283 Summary: Severaal test fail on Darwin with -gctf Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: iains at gcc dot gnu.org Target Milestone: --- Host: x86_64-apple-darwin20 Target: x86_64-apple-darwin20 Build: x86_64-apple-darwin20 Severaal test fail on Darwin with -gctf FAIL: gcc.dg/debug/20020220-1.c -gctf (test for excess errors) UNRESOLVED: gcc.dg/debug/20020220-1.c -gctf compilation failed to produce executable FAIL: gcc.dg/debug/20020327-1.c -gctf (test for excess errors) FAIL: gcc.dg/debug/20050907-1.c -gctf (test for excess errors) FAIL: gcc.dg/debug/pr29609-1.c -gctf (test for excess errors) UNRESOLVED: gcc.dg/debug/pr29609-1.c -gctf compilation failed to produce executable FAIL: gcc.dg/debug/pr29609-2.c -gctf (test for excess errors) UNRESOLVED: gcc.dg/debug/pr29609-2.c -gctf compilation failed to produce executable FAIL: gcc.dg/debug/pr36690-1.c -gctf (test for excess errors) UNRESOLVED: gcc.dg/debug/pr36690-1.c -gctf compilation failed to produce executable FAIL: gcc.dg/debug/pr36690-2.c -gctf (test for excess errors) UNRESOLVED: gcc.dg/debug/pr36690-2.c -gctf compilation failed to produce executable FAIL: gcc.dg/debug/pr36690-3.c -gctf (test for excess errors) UNRESOLVED: gcc.dg/debug/pr36690-3.c -gctf compilation failed to produce executable FAIL: gcc.dg/debug/pr37616.c -gctf (test for excess errors) UNRESOLVED: gcc.dg/debug/pr37616.c -gctf compilation failed to produce executable FAIL: gcc.dg/debug/pr41893-1.c -gctf (test for excess errors) FAIL: gcc.dg/debug/pr49032.c -gctf (test for excess errors) FAIL: gcc.dg/debug/pr65771.c -gctf (test for excess errors) FAIL: gcc.dg/debug/tls-1.c -gctf (test for excess errors) FAIL: gcc.dg/debug/trivial.c -gctf (test for excess errors) UNRESOLVED: gcc.dg/debug/trivial.c -gctf compilation failed to produce executable The errors are % /opt/gcc/gcc12w/bin/gcc /opt/gcc/work/gcc/testsuite/gcc.dg/debug/trivial.c -gctf /var/folders/ls/2kcvbftx2bj70mvvv8j7cclmgn/T//ccfWQsWN.s:1:15: error: unexpected token in '.section' directive .section .ctf ^
[Bug fortran/100971] ICE: Bad IO basetype (7)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100971 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-06-21 --- Comment #2 from Dominique d'Humieres --- > I can confirm this bug. Me too!
[Bug fortran/101123] [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101123 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from Dominique d'Humieres --- I think this PR should be closed as invalid. When using -fdefault_*, it is the user's responsibility to check that the promotion is compatible with procedure arguments: MAX0 is expecting INTEGER(4) and is given INTEGER(8). The code compiles if MAX0 is replaced with the generic function MAX.
[Bug fortran/100914] Bind(c): errors handling complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100914 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |ASSIGNED
[Bug fortran/100907] Bind(c): failure handling wide character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100907 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |ASSIGNED
[Bug fortran/100910] Bind(c): errors handling long double complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100910 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |NEW
[Bug fortran/100245] ICE on automatic reallocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100245 Dominique d'Humieres changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug fortran/100029] ICE on subroutine call with allocatable polymorphic assumed-rank argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100029 Dominique d'Humieres changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug fortran/100683] Array initialization refuses valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100683 --- Comment #6 from Dominique d'Humieres --- > Can you provide some more detail on your setup? program p integer, parameter :: a(2) = 1 integer, parameter :: b = a(2)%kind end I get the ICE with a patched master and a genuine GCC11 with only the patch at https://gcc.gnu.org/pipermail/fortran/2021-May/056053.html. COLLECT_GCC=gfc11 COLLECT_LTO_WRAPPER=/opt/gcc/gcc11w/libexec/gcc/x86_64-apple-darwin20.5.0/11.1.1/lto-wrapper Target: x86_64-apple-darwin20.5.0 Configured with: ../11_work/configure --prefix=/opt/gcc/gcc11w --enable-languages=c,c++,d,fortran,ada,lto,objc,obj-c++ --with-gmp=/opt/mp --with-isl=/opt/mp --enable-plugin --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk --with-as=/opt/mp/bin/as Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.1.1 20210612 [revision r11-8563-gf9cc49ecebfap1] (GCC) or COLLECT_GCC=gfc COLLECT_LTO_WRAPPER=/opt/gcc/gcc12w/libexec/gcc/x86_64-apple-darwin20.5.0/12.0.0/lto-wrapper Target: x86_64-apple-darwin20.5.0 Configured with: ../work/configure --prefix=/opt/gcc/gcc12w --enable-languages=c,c++,d,fortran,ada,lto,objc,obj-c++ --with-gmp=/opt/mp --with-isl=/opt/mp --enable-plugin --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk --with-as=/opt/mp/bin/as Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.0 20210612 (experimental) [master revision r12-1403-gc4e50e500da7p14] (GCC)
[Bug fortran/100961] Intrinsic function as value to a class(*) assumed rank argument fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100961 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-06-08 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- AFAIU the test it works for me with GCC10, 11, and 12. What is tour output of Fortran -v?
[Bug fortran/100907] Bind(c): failure handling wide character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100907 --- Comment #5 from Dominique d'Humieres --- > It seems that Mac OS doesn't have the full set of C11 standard headers... :-( Shouldn't the C11 standard headers be provide by GCC12? Nevertheless the test compiles with the new version of the new C companion. The same is true for 100910 and 100914.
[Bug fortran/100914] Bind(c): errors handling complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100914 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-06-05 Status|UNCONFIRMED |WAITING --- Comment #2 from Dominique d'Humieres --- On my system I get % gfc pr100914.f90 pr100914.c pr100914.c: In function 'c_vrfy_float_complex': pr100914.c:61:22: warning: implicit declaration of function 'CMPLXF' [-Wimplicit-function-declaration] 61 | if ((cabsf (*ip-(CMPLXF((float)(i+1), (float)(2*(i+1)>(float)0.0)) | ^~ pr100914.c: In function 'c_vrfy_double_complex': pr100914.c:98:21: warning: implicit declaration of function 'CMPLX' [-Wimplicit-function-declaration] 98 | if ((cabs (*ip-(CMPLX((double)(i+1), (double)(2*(i+1)>(double)0.0)) | ^ Undefined symbols for architecture x86_64: "_CMPLX", referenced from: _c_vrfy_double_complex in ccFYXXYa.o _c_vrfy_float128_complex in ccFYXXYa.o "_CMPLXF", referenced from: _c_vrfy_float_complex in ccFYXXYa.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status
[Bug fortran/100910] Bind(c): errors handling long double complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100910 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2021-06-05 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- On my system I get % gfc pr100910.f90 pr100910.c pr100910.c: In function 'c_vrfy_long_double_complex': c_vrfy_long_double_complex': pr100910.c:49:43: warning: implicit declaration of function 'CMPLX' [-Wimplicit-function-declaration] 49 | if ((cabsl (*ip-(long double complex)(CMPLX((double)(i+1), (double)(2*(i+1)>(long double)0.0)) | ^ Undefined symbols for architecture x86_64: "_CMPLX", referenced from: _c_vrfy_long_double_complex in ccyI5oZ3.o ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status
[Bug fortran/100907] Bind(c): failure handling wide character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100907 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2021-06-05 --- Comment #2 from Dominique d'Humieres --- On my system I get % gfc pr100907.f90 pr100907.c pr100907.c:4:10: fatal error: uchar.h: No such file or directory 4 | #include | ^ compilation terminated.
[Bug fortran/100855] pow run time gfortran vs ifort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100855
Dominique d'Humieres changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING |RESOLVED
--- Comment #9 from Dominique d'Humieres ---
I don't know if the test is coming from a real world problem. The modified test
program power
implicit none
real :: sum, sum1, n, q
integer :: i, j
integer :: limit
real :: start, finish
sum = 0d0
sum1 = 0d0
limit = 1
n = 2.0
q = 0.5
call CPU_TIME(start)
do i=1, limit
n = n*q
sum1 = sum1 + (i ** (0.05 + n))
end do
do i=1, limit
sum = sum + (i ** 0.05)
end do
sum = sum1 + (limit-1)*sum
call CPU_TIME(finish)
print *, sum, n, sum1
print '("Time = ",f6.3," seconds.")',finish-start
end program power
yields
150945680. 0. 15095.7852
Time = 0.000 seconds.
[Bug fortran/100855] pow run time gfortran vs ifort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100855 --- Comment #8 from Dominique d'Humieres --- > So gnu is indeed faster for real(8), but the result was changed. What OS are you using? In any sensible library REAL(4° should be faster than REAL(8). > notice the result was also changed REAL(4): 33554432.0 REAL(8): 150945570.07620683 REAL(16): 150945570.075233660889594015556531239 I did not do a full numerical analysis, but it is known that SUM is very limited for REAL(4).
[Bug fortran/100855] pow run time gfortran vs ifort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100855 --- Comment #6 from Dominique d'Humieres --- On a MacOS, Corei9, 2.4Ghz, the program runs in ~1s, almost indpendtly of the option level. This PR remind me an old problem in which the transcendental functions were almost slower for REAL(4) then for REAL(8) on some Unix distros (Fedora(?), based of "correct rounding"). What are your timings if you replace real :: sum, n, q with real(8) :: sum, n, q and sum = sum + (i ** (0.05 + n)) with sum = sum + (i ** (0.05_8 + n)) ?
[Bug fortran/100860] class(*) type is (character(*)) produces a segmentation fault when run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100860 --- Comment #2 from Dominique d'Humieres --- WORKSFORME from GCC7 up to trunk.
[Bug fortran/96012] [9/10/11/12 Regression] ICE in fold_convert_loc, at fold-const.c:2558
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96012 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #8 from Dominique d'Humieres --- > This PR appears to remain an 8-only regression, as the testcases in comment#0 > do compile now. GCC8 is closed, so closing.
[Bug fortran/70949] Invalid aggregate against pointer comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70949 --- Comment #5 from Dominique d'Humieres --- > his PR appears to have been fixed between r11-6743 and r11-6879. Confirmed. Could someone be kind enough to add the test to the test suite?
[Bug other/35014] Libgfortran.a (downloaded) is not PIC compiled...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35014 Dominique d'Humieres changed: What|Removed |Added Component|libfortran |other --- Comment #12 from Dominique d'Humieres --- No feedback. This is not a libgfortran bug, moving.
[Bug fortran/88356] [9/10/11/12 Regression] ICE with -Werror in reduce_binary_ac, at fortran/arith.c:1318 (and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88356 Dominique d'Humieres changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #9 from Dominique d'Humieres --- > Has this been "accidentally" solved? Apparently yes, closing.
[Bug target/94324] [10/11/12 regression] gfortran.dg/default_format_1.f90 etc. FAIL on 32-bit Solaris/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94324 Dominique d'Humieres changed: What|Removed |Added Component|fortran |target --- Comment #8 from Dominique d'Humieres --- > Shouldn't the component moved to target? No feedback for almost a year, doing so.
[Bug fortran/60576] [9/10/11/12 Regression] FAIL: gfortran.dg/assumed_rank_7.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576 --- Comment #34 from Dominique d'Humieres --- I still get ==33027==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffee0fa7e08 at pc 0x00010ef9b521 bp 0x7ffee0fa7a40 sp 0x7ffee0fa71f0 ... with GCC12 and gfc /opt/gcc/_clean/gcc/testsuite/gfortran.dg/assumed_rank_7.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -fsanitize=address
[Bug fortran/96859] Wrong answer with intrinsic merge_bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96859 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #14 from Dominique d'Humieres --- > Anything left to do or can the PR be closed? I think so. Please reopen if I missed something.
[Bug fortran/100683] Array initialization refuses valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100683 --- Comment #4 from Dominique d'Humieres --- Sorry I didn't use the right compiler. If I do so, I get * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) frame #0: 0x000101443613 f951`splay_tree_min(sp=0x00010001) at splay-tree.c:501:11 498if (!n) 499 return NULL; 500 -> 501while (n->left) 502 n = n->left; 503 504return n; Target 0: (f951) stopped. (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) * frame #0: 0x000101443613 f951`splay_tree_min(sp=0x00010001) at splay-tree.c:501:11 frame #1: 0x00010002048e f951`gfc_constructor_first(base=) at constructor.c:234:45 frame #2: 0x000164d3 f951`::expand_constructor(base=) at array.c:1790:34 frame #3: 0x00018176 f951`gfc_expand_constructor(gfc_expr*, bool) at array.c:1852:27 frame #4: 0x000180f5 f951`gfc_expand_constructor(e=0x000144505af0, fatal=) at array.c:1875 frame #5: 0x0001000c339f f951`gfc_resolve_expr(gfc_expr*) (.part.0) at resolve.c:7144:29 frame #6: 0x0001000435ea f951`::find_inquiry_ref(p=, newp=0x7ffeefbfe268) at expr.c:1778:20 frame #7: 0x000100047056 f951`::simplify_ref_chain(ref=0x000144505ea0, type=0, p=0x7ffeefbfe2a8) at expr.c:2029:26 frame #8: 0x0001000464be f951`gfc_simplify_expr(gfc_expr*, int) at expr.c:2268:31 frame #9: 0x000100046e2d f951`::simplify_parameter_variable(p=0x0001445049b0, type=0) at expr.c:2112:25 frame #10: 0x000100046bd1 f951`gfc_simplify_expr(gfc_expr*, int) at expr.c:2055:3 frame #11: 0x0001000b4c74 f951`gfc_match_varspec(gfc_expr*, int, bool, bool) at primary.c:2421:22 frame #12: 0x0001000b6bf7 f951`gfc_match_rvalue(result=0x7ffeefbfe598) at primary.c:3590:29 frame #13: 0x000100080218 f951`::match_mult_operand(gfc_expr **) at matchexp.c:157:24 frame #14: 0x000100080200 f951`::match_mult_operand(gfc_expr **) at matchexp.c:211 frame #15: 0x000100080200 f951`::match_mult_operand(result=0x7ffeefbfe660) at matchexp.c:267 frame #16: 0x00010008055d f951`::match_add_operand(result=0x7ffeefbfe6c8) at matchexp.c:356:26 frame #17: 0x00010008083e f951`::match_level_2(result=0x7ffeefbfe740) at matchexp.c:480:27 frame #18: 0x000100080a1d f951`::match_level_3(result=0x7ffeefbfe7c0) at matchexp.c:551:21 frame #19: 0x000100080b66 f951`::match_and_operand(gfc_expr **) at matchexp.c:599:21 frame #20: 0x000100080b5c > This test compiles under lldb. f951`::match_and_operand(result=0x7ffeefbfe840) at matchexp.c:693 frame #21: 0x000100080d9d f951`::match_or_operand(result=0x7ffeefbfe8c0) at matchexp.c:722:25 frame #22: 0x000100080ebd f951`::match_equiv_operand(result=0x7ffeefbfe940) at matchexp.c:765:24 frame #23: 0x000100080fdd f951`::match_level_5(result=0x7ffeefbfe990) at matchexp.c:811:27 frame #24: 0x000100080047 f951`gfc_match_expr(result=0x7ffeefbfea28) at matchexp.c:870:21 frame #25: 0x000100049368 f951`gfc_match_init_expr(result=0x7ffeefbfeaa0) at expr.c:3130:22 frame #26: 0x00010003259b f951`gfc_match_data_decl() at decl.c:2884:28 frame #27: 0x0001000a3d12 f951`::decode_statement() at parse.c:65:15 frame #28: 0x0001000a3d0d f951`::decode_statement() at parse.c:376 frame #29: 0x0001000a9195 f951`next_statement() at parse.c:1321:27 frame #30: 0x0001000ab91c f951`parse_spec(gfc_statement) at parse.c:3981:27 frame #31: 0x0001000aeaf4 f951`::parse_progunit(st=ST_NONE) at parse.c:5918:19 frame #32: 0x0001000b06de f951`gfc_parse_file() at parse.c:6459:22 frame #33: 0x0001001052ac f951`gfc_be_parse_file() at f95-lang.c:212:18 frame #34: 0x000100ec4df4 f951`::compile_file() at toplev.c:457:25 frame #35: 0x00010168c17f f951`toplev::main(int, char**) at toplev.c:2203:24 frame #36: 0x00010168e411 f951`main(argc=2, argv=0x7ffeefbff0c8) at main.c:39:23
[Bug fortran/34040] Support for DOUBLE_TYPE_SIZE != 64 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #17 from Dominique d'Humieres --- Target issue?
[Bug fortran/100683] Array initialization refuses valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100683 --- Comment #3 from Dominique d'Humieres --- Using an instrumented compiler I get % gfcg pr87993.f90 ../../work/libiberty/splay-tree.c:496:19: runtime error: member access within misaligned address 0x00010001 for type 'struct splay_tree_s', which requires 8 byte alignment 0x00010001: note: pointer points here ../../work/libiberty/splay-tree.c:501:11: runtime error: member access within misaligned address 0x30107feedfa for type 'struct splay_tree_node_s', which requires 8 byte alignment 0x30107feedfa: note: pointer points here f951: internal compiler error: Segmentation fault: 11
[Bug fortran/100813] Function of array of pointers to abstract class returning an array since r6-202-gf3b0bb7a560be0f0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100813 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-31 Status|UNCONFIRMED |NEW
[Bug fortran/100683] Array initialization refuses valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100683 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-05-31 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056053.html The patch fixes this PR, however I see an ICE on the original test for pr87993: % gfc pr87993.f90 f951: internal compiler error: Segmentation fault: 11 This test compiles under lldb. Note that the test in the test suite compiles.
[Bug fortran/94331] Bind(C) corrupts array descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331 --- Comment #11 from Dominique d'Humieres --- > I have fixed the glaring mistake in PR94331.c, could you be so gentle > as to test it to verify that it does indeed solve the problems you found? The problem seems solved with the updated PR94331.c. Thanks.
[Bug fortran/93308] bind(c) subroutine changes lower bound of array argument in caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93308 Dominique d'Humieres changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056054.html The patch fixes this PR, see also pr94331.
[Bug fortran/93963] Select rank mishandling allocatable and pointer arguments with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93963 Dominique d'Humieres changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056054.html The patch fixes this PR, see also pr94331.
[Bug fortran/97046] Bad interaction between lbound/ubound, allocatable arrays and bind(C) subroutine with dimension(..) parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97046 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-30 Status|UNCONFIRMED |ASSIGNED --- Comment #7 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056054.html The patch fixes this PR, see also pr94331.
[Bug fortran/94327] Bind(c) argument attributes are incorrectly set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94327 Dominique d'Humieres changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056054.html The patch fixes this PR, see also pr94331.
[Bug fortran/94331] Bind(C) corrupts array descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331 --- Comment #8 from Dominique d'Humieres --- Easier to read warnings: pr94331_1.f90:121:10: warning: type of 'checkb_o_ar' does not match original declaration [-Wlto-type-mismatch] 121 | if(.not.checkb_o_ar(a, 0, ex-1))stop 28 | ^ pr94331_1.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ pr94331_1.c:38:1: note: type 'CFI_index_t' should match type 'int' pr94331_1.f90:111:10: warning: type of 'checkb_o_as' does not match original declaration [-Wlto-type-mismatch] 111 | if(.not.checkb_o_as(a, 0, ex-1))stop 20 | ^ pr94331_1.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ pr94331_1.c:38:1: note: type 'CFI_index_t' should match type 'int' pr94331_1.f90:101:10: warning: type of 'checkb_p_ar' does not match original declaration [-Wlto-type-mismatch] 101 | if(.not.checkb_p_ar(a, lb, ub)) stop 12 | ^ pr94331_1.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ pr94331_1.c:38:1: note: type 'CFI_index_t' should match type 'int' pr94331_1.f90:91:10: warning: type of 'checkb_p_as' does not match original declaration [-Wlto-type-mismatch] 91 | if(.not.checkb_p_as(a, lb, ub)) stop 4 | ^ pr94331_1.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ pr94331_1.c:38:1: note: type 'CFI_index_t' should match type 'int' pr94331_1.f90:167:10: warning: type of 'checkb_a_ar' does not match original declaration [-Wlto-type-mismatch] 167 | if(.not.checkb_a_ar(b, lb, ub)) stop 63 | ^ pr94331_1.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ pr94331_1.c:38:1: note: type 'CFI_index_t' should match type 'int' pr94331_1.f90:155:10: warning: type of 'checkb_a_as' does not match original declaration [-Wlto-type-mismatch] 155 | if(.not.checkb_a_as(b, lb, ub)) stop 54 | ^ pr94331_1.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ pr94331_1.c:38:1: note: type 'CFI_index_t' should match type 'int' pr94331_1.c:38:1: note: 'check_bounds' was previously declared here pr94331_1.c:38:1: note: code may be misoptimized unless '-fno-strict-aliasing' is used Note that the test passes with -Wno-lto-type-mismatch.
[Bug fortran/94331] Bind(C) corrupts array descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #7 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056054.html With the patch the test PR94331.f90 fails with -flto: % gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.f90 /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c -flto /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.f90:121:10: warning: type of 'checkb_o_ar' does not match original declaration [-Wlto-type-mismatch] 121 | if(.not.checkb_o_ar(a, 0, ex-1))stop 28 | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type 'CFI_index_t' should match type 'int' /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.f90:111:10: warning: type of 'checkb_o_as' does not match original declaration [-Wlto-type-mismatch] 111 | if(.not.checkb_o_as(a, 0, ex-1))stop 20 | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type 'CFI_index_t' should match type 'int' /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.f90:101:10: warning: type of 'checkb_p_ar' does not match original declaration [-Wlto-type-mismatch] 101 | if(.not.checkb_p_ar(a, lb, ub)) stop 12 | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type 'CFI_index_t' should match type 'int' /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.f90:91:10: warning: type of 'checkb_p_as' does not match original declaration [-Wlto-type-mismatch] 91 | if(.not.checkb_p_as(a, lb, ub)) stop 4 | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type 'CFI_index_t' should match type 'int' /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.f90:167:10: warning: type of 'checkb_a_ar' does not match original declaration [-Wlto-type-mismatch] 167 | if(.not.checkb_a_ar(b, lb, ub)) stop 63 | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type 'CFI_index_t' should match type 'int' /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.f90:155:10: warning: type of 'checkb_a_as' does not match original declaration [-Wlto-type-mismatch] 155 | if(.not.checkb_a_as(b, lb, ub)) stop 54 | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type mismatch in parameter 2 38 | check_bounds (const CFI_cdesc_t *restrict auxp, const CFI_index_t lb, const CFI_index_t ub) | ^ /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: type 'CFI_index_t' should match type 'int' /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: 'check_bounds' was previously declared here /opt/gcc/work/gcc/testsuite/gfortran.dg/PR94331.c:38:1: note: code may be misoptimized unless '-fno-strict-aliasing' is used Note that the original test seems fixed even with -flto.
[Bug fortran/100816] Wrong span on widechar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100816 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2021-05-30 --- Comment #2 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056097.html The patch works as expected.
[Bug fortran/100818] A temporary is passed to associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100818 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-05-30 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056097.html The patch works as expected.
[Bug fortran/100819] Wrong code generation with unlimited polymorphic objects and character type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100819 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-05-30 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056097.html The patch works as expected.
[Bug fortran/100120] associated intrinsic failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100120 Dominique d'Humieres changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056097.html The patch works as expected.
[Bug fortran/100821] Deferred character with wrong length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100821 Dominique d'Humieres changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug fortran/100821] Deferred character with wrong length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100821 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-05-29 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- > Patch posted: > > https://gcc.gnu.org/pipermail/fortran/2021-May/056097.html The patch works as expected.
[Bug middle-end/100755] Error with fortran object (v11.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100755 --- Comment #4 from Dominique d'Humieres --- > If I'm understanding correctly and this is an extension being deprecated, > is there any option to push the compilation with gcc11.1 through? Did you try -std=legcy?
[Bug fortran/100602] [11/12 Regression] Erroneous "pointer argument is not associated" runtime error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100602 Dominique d'Humieres changed: What|Removed |Added Known to fail||11.1.0, 12.0 Known to work||10.3.0 Priority|P3 |P4 Keywords||rejects-valid Target Milestone|--- |11.2 Summary|Erroneous "pointer argument |[11/12 Regression] |is not associated" runtime |Erroneous "pointer argument |error. |is not associated" runtime ||error. --- Comment #2 from Dominique d'Humieres --- This looks like a regression.
[Bug fortran/100607] ICE with SELECT RANK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100607 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-05-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug bootstrap/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-04-29 CC||iains at gcc dot gnu.org --- Comment #3 from Dominique d'Humieres --- Confirmed.
[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 --- Comment #11 from Dominique d'Humieres --- > I don't think I have the necessary permissions, but I may be missing > something > obvious... Did you try to click on 'take' in Assignee: Not yet assigned to anyone (edit) (take) ? If you have write access to git, I'ld be surprised that you have permissions problem for Bugzilla.
[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-04-26 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #9 from Dominique d'Humieres --- > Patch (version 2) posted: > > https://gcc.gnu.org/pipermail/fortran/2021-April/055991.html Please assign the PR to yourself when you submit a patch!
[Bug fortran/100218] Allow target of the pointer resulting from the evaluation of function-reference in a variable definition context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100218 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-24
[Bug fortran/100245] ICE on automatic reallocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100245 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-04-24 Priority|P3 |P4 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Dominique d'Humieres --- Confirmed since at least GCC7.
[Bug fortran/97571] long parsing phase for simple array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97571 Dominique d'Humieres changed: What|Removed |Added CC||molah at ucar dot edu --- Comment #4 from Dominique d'Humieres --- *** Bug 100235 has been marked as a duplicate of this bug. ***
[Bug fortran/100235] 10.3.0 Performance regressions for compile-time math intrinsics computation on arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100235 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Dominique d'Humieres --- Dup. *** This bug has been marked as a duplicate of bug 97571 ***
[Bug fortran/100227] [8/9/10/11/12 Regression] write with implicit loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100227 Dominique d'Humieres changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Known to fail||11.0, 12.0 Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-23 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Workaround: use -fno-frontend-optimize.
[Bug c++/99936] [modules] FAIL: g++.dg/modules/xtreme-header* on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936 Dominique d'Humieres changed: What|Removed |Added CC||nathan at gcc dot gnu.org Blocks||99227 Ever confirmed|0 |1 Summary|FAIL: |[modules] FAIL: |g++.dg/modules/xtreme-heade |g++.dg/modules/xtreme-heade |r* on Darwin|r* on Darwin Last reconfirmed||2021-04-19 Status|UNCONFIRMED |NEW --- Comment #1 from Dominique d'Humieres --- See also https://gcc.gnu.org/pipermail/gcc-testresults/2021-April/682945.html and friends. It would be nice to have this PR fixed for GCC 11.1! Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227 [Bug 99227] [meta] [modules] Bugs relating to header-units of STL header files
[Bug fortran/96013] ICE in write_symbol, at fortran/module.c:5747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96013 --- Comment #13 from Dominique d'Humieres --- The following variant gives an ICE type t end type contains function f() result(t) character(3) :: c c = 'abc' end end The back trace is * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) * frame #0: 0x7fff206945d2 libsystem_platform.dylib`_platform_strlen + 18 frame #1: 0x000100e99509 f951`get_identifier(text=0x) at stringpool.c:95:32 frame #2: 0x00010012b302 f951`::build_function_decl(gfc_symbol *, bool) [inlined] gfc_sym_identifier(sym=) at trans-decl.c:366:10 frame #3: 0x00010012b2d5 f951`::build_function_decl(sym=0x00014331e0b0, global=) frame #4: 0x000100139a3b f951`gfc_generate_function_code(gfc_namespace*) [inlined] gfc_create_function_decl(global=, ns=0x00014403da00) at trans-decl.c:3082:23 frame #5: 0x000100139a2d f951`gfc_generate_function_code(gfc_namespace*) [inlined] gfc_generate_contained_functions(parent=0x000144038e00) frame #6: 0x000100139a03 f951`gfc_generate_function_code(ns=0x000144038e00) frame #7: 0x0001000b04c4 f951`gfc_parse_file() at parse.c:6354:25 frame #8: 0x0001001049bc f951`::gfc_be_parse_file() at f95-lang.c:212:18 frame #9: 0x000100ea0264 f951`::compile_file() at toplev.c:457:25 frame #10: 0x0001016597cf f951`toplev::main(int, char**) at toplev.c:2201:24 frame #11: 0x00010165948e f951`toplev::main(this=0x7ffeefbff09e, argc=, argv=) frame #12: 0x00010165b9e1 f951`main(argc=2, argv=0x7ffeefbff0d8) at main.c:39:22 Is the code valid?
[Bug fortran/99255] ICE in gfc_dt_upper_string, at fortran/module.c:441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99255 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-04-18 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug fortran/100132] Optimization breaks pointer association
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100132 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-04-18 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Dominique d'Humieres --- Confirmed since at least GCC7.
[Bug fortran/100120] associated intrinsic failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100120 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-16 --- Comment #1 from Dominique d'Humieres --- Confirmed since at least GCC7.
[Bug fortran/100118] ICE on sizeof with derived type components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100118 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-04-16 --- Comment #1 from Dominique d'Humieres --- Confirmed since at least GCC7.
[Bug fortran/100103] Automatic reallocation fails inside select rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100103 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-04-16 --- Comment #1 from Dominique d'Humieres --- Patch at https://gcc.gnu.org/pipermail/fortran/2021-April/055934.html.
[Bug fortran/100098] Polymorphic pointers and allocatables have incorrect rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100098 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-04-16 Status|UNCONFIRMED |NEW --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug fortran/100097] Unlimited polymorphic pointers and allocatables have incorrect rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100097 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-04-16 Status|UNCONFIRMED |NEW --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug fortran/100094] Undefined pointers have incorrect rank when using optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100094 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-04-16 Status|UNCONFIRMED |NEW --- Comment #2 from Dominique d'Humieres --- Confirmed.
[Bug fortran/100040] Wrong code with intent out assumed-rank allocatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100040 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-14 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug fortran/100029] ICE on subroutine call with allocatable polymorphic assumed-rank argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100029 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-04-14 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed since at least GCC7.
[Bug fortran/100027] ICE on storage_size with polymorphic argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100027 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-14 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed since at least GCC7. Likely a duplicate of pr84006.
[Bug fortran/100025] [10/11 Regression] ICE on subroutine missing explicit interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100025 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100024 Known to work||9.3.1 Known to fail||10.3.1, 11.0 Summary|ICE on subroutine missing |[10/11 Regression] ICE on |explicit interface |subroutine missing explicit ||interface Target Milestone|--- |10.4 Status|UNCONFIRMED |NEW Keywords||ice-on-invalid-code Last reconfirmed||2021-04-14 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed.
[Bug fortran/100024] [10/11 Regression] ICE on subroutine missing explicit interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100024 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-invalid-code Summary|ICE on subroutine missing |[10/11 Regression] ICE on |explicit interface |subroutine missing explicit ||interface Known to work||9.3.1 Known to fail||10.3.0, 11.0 Last reconfirmed||2021-04-14 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Dominique d'Humieres --- Confirmed.
