https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828
--- Comment #5 from Rich Townsend ---
One more data point: I tried with gfortran 13.2.0 on Linux/Intel and get the
same result as for 13.1.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828
--- Comment #4 from Rich Townsend ---
Another data point for MacOS/Intel (10.13.6, High Sierra) -- with the character
vars set to length 64, the crash is as follows:
test(3287,0x7fff8fc11380) malloc: *** error for object 0x7fe44cc03b58:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828
--- Comment #3 from Rich Townsend ---
I can get the MWE to barf on MacOS/Arm (Sonoma 14.1.1), gfortran 13.1.0, by
changing the length of the character vars in the main program from 64 to 16.
The error is now:
In file 'test.f90', around line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828
--- Comment #2 from Rich Townsend ---
The problem manifests with gfortran 13.1.0 on Linux/x86_64. I've run into
similar looking problems on MacOS/Arm, but the MWE I provided seems to work OK
on Arm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828
Bug ID: 112828
Summary: Abort with malloc(): corrupted top size
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110877
Bug ID: 110877
Summary: Incorrect copy of allocatable component in polymorphic
assignment from array dummy argument
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659
--- Comment #9 from Rich Townsend ---
OK, I managed to get things working by setting
export LDFLAGS='-Wl,--no-eh-frame-hdr'
prior to configuring. I'm hoping this won't affect the functionality of the
built compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659
--- Comment #7 from Rich Townsend ---
(In reply to Andrew Pinski from comment #6)
> GCC 13 won't build with anything older than GCC 4.8.x as documented at
> https://gcc.gnu.org/install/prerequisites.html (which is right now for the
> trunk but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659
--- Comment #5 from Rich Townsend ---
(In reply to Andrew Pinski from comment #2)
> What compiler did you start with?
> That is what is the output of `x86_64-pc-linux-gnu-g++ -v` ?
[user@60947d0cbd04 ~]$ x86_64-pc-linux-gnu-g++ -v
bash:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659
--- Comment #4 from Rich Townsend ---
Someone else seems to have the same problem:
https://stackoverflow.com/questions/76375244/how-can-i-resolve-a-ld-eh-frame-hdr-refers-to-overlapping-fdes-error-during
...although there is no fix suggested.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659
--- Comment #1 from Rich Townsend ---
I should add that this is on CentOS 5.11, running inside a Docker container.
This ships with a very old binutils, so before trying to compile gcc I
installed binutils 2.40 (built from source with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110659
Bug ID: 110659
Summary: Error from linker: .eh_frame_hdr refers to overlapping
FDEs
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110650
--- Comment #3 from Rich Townsend ---
Sure thing:
GNU ld version 2.17.50.0.6-26.el5 20061020
I'm deliberately working with an old toolchain, inside a Docker container, to
make sure that when I distribute the gcc executables they will work OK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110650
--- Comment #1 from Rich Townsend ---
Oops, posted without any bug description!
I'm trying to build gcc 13.1.0 on Linux x86_64, and I get the following
segfault:
libtool: compile: /home/user/sdk2-tmp/build/gcc-build/./gcc/xgcc
-shared-libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110650
Bug ID: 110650
Summary: collect2: fatal error: ld terminated with signal 11
[Segmentation fault]
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110629
--- Comment #3 from Rich Townsend ---
Thanks for the quick responses, folks. The problem persists in 12.3.0 release,
but is fixed in 13.1.0 release.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110629
Bug ID: 110629
Summary: Bug in assignment of derived type with deferred length
character component
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105205
Bug ID: 105205
Summary: Incorrect assignment of derived type with allocatable,
deferred-length character component
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
Rich Townsend changed:
What|Removed |Added
CC||townsend at astro dot wisc.edu
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99477
Bug ID: 99477
Summary: CONTIGUOUS assumed-shape dummy not working with
associate construct
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99169
Bug ID: 99169
Summary: Segfault when passing allocatable scalar into
intent(out) dummy argument
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98445
--- Comment #3 from Rich Townsend ---
OK, my code isn't valid -- it's not permitted to pass a generic procedure name
as an actual argument. As such, gfortran is correct in its behavior.
Happy for this one to be closed -- sorry for the false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98445
--- Comment #2 from Rich Townsend ---
I know it's acceptable to overload a type name with one or more functions --
from 12.4.3.4.1 of the F2008 standard,
"A generic name may be the same as a derived-type name, in which case all of
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98445
Bug ID: 98445
Summary: Bogus error: derived type used as an actual argument
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
24 matches
Mail list logo
