https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97683
--- Comment #2 from sandra at gcc dot gnu.org ---
I'm pretty sure this is a gas bug. I used git bisect to track it down to
binutils commit ae9d2233e61a98ff8dba56be10219aa5306ffc9a which caused gcc to
start passing --gdwarf-5 on the gas command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93524
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93524
--- Comment #7 from sandra at gcc dot gnu.org ---
Now applied to GCC 11 too. The other two patches referenced in this issue were
put on mainline before GCC 11 branched and not on GCC 10 or any older branch,
so I think I'm done here and the issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331
--- Comment #4 from sandra at gcc dot gnu.org ---
OK, there are two flavors of failures being diagnosed by the test case.
The first flavor involves the lower bounds of an array passed into a bind(c)
procedure being set to zero in the callee when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93963
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94289
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93308
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101320
Bug ID: 101320
Summary: Bind(C): Missing diagnostic for constraint C1557 on
allocatable/pointer arguments
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101317
Bug ID: 101317
Summary: Bind(C): improve error checking in CFI_* functions
declared in ISO_Fortran_binding.h
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101319
Bug ID: 101319
Summary: Missing diagnostic for argument with type parameters
for assumed-type dummy
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101305
sandra at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621
--- Comment #18 from sandra at gcc dot gnu.org ---
The short answer re the TS 29113 thing is that it's what the customer who's
funding the work asked us to do. :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101305
Bug ID: 101305
Summary: Bind(C): Problems with incorrect kinds/sizes in
ISO_Fortran_binding.h and CFI_establish
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101304
Bug ID: 101304
Summary: Bind(C): CONTIGUOUS attribute not handled correctly in
Fortran routines called from C with discontiguous
argument
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101308
Bug ID: 101308
Summary: Bind(C): gfortran does not create C descriptors for
scalar pointer/allocatable arguments
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93308
--- Comment #8 from sandra at gcc dot gnu.org ---
I tested the second version of the patch; it does fix the bug I observed with
an assumed-rank array argument in a Fortran subroutine with C binding called
from C having lower bound 0 instead of 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101309
Bug ID: 101309
Summary: Bind(C): gfortran creates invalid C descriptor for
result of TRANSPOSE intrinsic
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101309
--- Comment #1 from sandra at gcc dot gnu.org ---
BTW, I did not test any other intrinsics that rearrange the elements of their
input array arguments. TRANPOSE seemed like the most obvious one to try first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101310
Bug ID: 101310
Summary: Bind(C): CFI_section seems confused by pointer arrays
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917
--- Comment #5 from sandra at gcc dot gnu.org ---
Here's a related problem: the GFC descriptor representation can't distinguish
between
CHARACTER(kind=ucs4, len=1)
and
CHARACTER(kind=c_char, len=4)
because all it has is elem_len == 4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917
--- Comment #6 from sandra at gcc dot gnu.org ---
I've been thinking some more about this issue. It seems to me that a "proper"
solution is either (1) Add a kind field to the GFC descriptor or (2) Do away
with GFC descriptors and use the C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54753
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101334
Bug ID: 101334
Summary: gfortran fails to enforce C838 on disallowed uses of
assumed-rank variable names + bogus errors
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101333
Bug ID: 101333
Summary: gfortran fails to enforce C711 on assumed-type actual
arguments
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101305
--- Comment #1 from sandra at gcc dot gnu.org ---
There's also some overlap with PR 100917, relating to long double. Getting rid
of the hard-coded kind/size assumptions will take care of at least the C side
of that issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101337
Bug ID: 101337
Summary: gfortran doesn't diagnose all operands with constraint
violations
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99250
Bug ID: 99250
Summary: [F2018] coshape intrinsic is missing
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070
sandra at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100914
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917
--- Comment #8 from sandra at gcc dot gnu.org ---
There is a workaround for this included in commit
93b6b2f614eb692d1d8126ec6cb946984a9d01d7
that doesn't fully solve the problem: when "long double" and "float128" are
different types with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102282
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102353
Bug ID: 102353
Summary: powerpc64le-linux-gnu build failure when build != host
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102353
--- Comment #4 from sandra at gcc dot gnu.org ---
I think rs6000-gen-builtins is supposed to be a build binary, not a host
binary? I'm seeing this at the end of my build log with that patch.
./rs6000-gen-builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102353
--- Comment #1 from sandra at gcc dot gnu.org ---
Ooops, I meant x86_64-linux-gnu build, not host. :-(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101305
--- Comment #3 from sandra at gcc dot gnu.org ---
Patches posted:
https://gcc.gnu.org/pipermail/fortran/2021-July/056236.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101835
Bug ID: 101835
Summary: Fortran 128-bit float support
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101310
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101317
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101305
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93308
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070
--- Comment #11 from sandra at gcc dot gnu.org ---
There are still some bugs present with class arrays. E.g., this test case
ICEs:
module m
type :: t
integer :: id
real :: xyz(3)
end type
contains
subroutine testit2p(a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101319
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94022
Bug 94022 depends on bug 94070, which changed state.
Bug 94070 Summary: Assumed-rank arrays – bounds mishandled,
SIZE/SHAPE/UBOUND/LBOUND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101304
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54753
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101333
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101320
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621
--- Comment #21 from sandra at gcc dot gnu.org ---
Tobias, did your big patch fully fix this issue so that we can close it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101334
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100916
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100907
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101337
--- Comment #1 from sandra at gcc dot gnu.org ---
This is likely a "won't fix" bug, but I'll leave it open for now. The test
cases (now committed) are still XFAILed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102641
Bug ID: 102641
Summary: Bogus error for intent(out) dummy that is a
polymorphic assumed-rank array
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54753
--- Comment #5 from sandra at gcc dot gnu.org ---
Patch to add the diagnostic posted here:
https://gcc.gnu.org/pipermail/fortran/2021-October/056656.html
There's still a problem with the bogus diagnostic arising from
deallocation/initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102641
--- Comment #2 from sandra at gcc dot gnu.org ---
I was thinking that for assumed-rank the front end should probably just emit a
call to a library support function in the callee, instead of whatever it is
doing now to try to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77652
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92701
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100911
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100914
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100915
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100910
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100906
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49111
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95375
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79330
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390
--- Comment #5 from sandra at gcc dot gnu.org ---
Created attachment 52107
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52107=edit
-fdump-tree-original output from second test case
Well, this is nuts. Unmodified code is generating 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390
--- Comment #4 from sandra at gcc dot gnu.org ---
I thought I had a fix for this that involved making gfc_is_simply_contiguous
smarter about intrinsics and other function calls, but after writing more test
cases I found that this one still ICEs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258
--- Comment #5 from sandra at gcc dot gnu.org ---
The previous hacky patch had some testsuite regressions. I've posted a less
hacky one that doesn't trigger new failures here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587632.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95879
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390
--- Comment #9 from sandra at gcc dot gnu.org ---
Without a test case, I can't tell if the error in comment 7 was due to this bug
or a different one. It doesn't really look the same as the other failures I
looked at in this issue, as the source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103898
--- Comment #4 from sandra at gcc dot gnu.org ---
This is probably related to my rewrite of the size/shape/ubound/lbound
intrinsics back in mid-November. I can add this one to my queue, but I've
already got 3 or 4 other issues already waiting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390
--- Comment #6 from sandra at gcc dot gnu.org ---
Patch posted:
https://gcc.gnu.org/pipermail/fortran/2022-January/057249.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103163
Bug ID: 103163
Summary: stack_limit_rtx is created too early
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101674
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92879
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103258
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103166
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102910
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99250
--- Comment #2 from sandra at gcc dot gnu.org ---
Hmmm. I've been going through the list at
https://gcc.gnu.org/wiki/Fortran2018Status
and there really are a large number of unimplemented F2018 features, not just
this one. :-( Anyway, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92482
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||everythingfunctional@proton
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98342
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100917
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94289
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99922
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95196
sandra at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102910
--- Comment #9 from sandra at gcc dot gnu.org ---
I will rewrite this testcase not to use alloca.
This particular case was originally XFAIL'ed at runtime because the
functionality it was supposed to test (assumed-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101337
sandra at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89078
Bug 89078 depends on bug 35276, which changed state.
Bug 35276 Summary: Doc should described how to compile mixed-language programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35930
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276
sandra at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot
1 - 100 of 188 matches
Mail list logo
