https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117514
--- Comment #7 from Jordan <8e3g6jay6 at mozmail dot com> ---
I'm going to keep this open, but I'm going to use the "fix" I came up with
where we push the c_ptr into a variable instead of inlining it.
I have 2 possible reasons this is happening,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117514
--- Comment #6 from Jordan <8e3g6jay6 at mozmail dot com> ---
I know I'm rambling a lot in here, but I have narrowed this down even further:
type(c_ptr) :: blah
blah = c_loc(required_extension)
call required_device_extensions%push_back(blah)
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117514
--- Comment #5 from Jordan <8e3g6jay6 at mozmail dot com> ---
Here is the functioning code in case this helps, I was basically transferring
in a C
char ** but I made the mistake of treating it as a char *. Hopefully this helps
debug this strange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117514
--- Comment #4 from Jordan <8e3g6jay6 at mozmail dot com> ---
I should also clarify, the main thing that I changed was
call required_device_extensions%push_back(c_loc(required_extension))
to this
call required_device_extensions%push_back(requi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117514
--- Comment #3 from Jordan <8e3g6jay6 at mozmail dot com> ---
So another update to this. If I do it like this, I simply get a crash of:
Operating system error: Cannot allocate memory
Memory allocation failure in xrealloc
function check_device
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117514
--- Comment #2 from Jordan <8e3g6jay6 at mozmail dot com> ---
(In reply to Jordan from comment #1)
> Oh, very sorry. I forgot to include the traceback
>
> vulkan_driver_select_physical_device.f9failed.
> [ 20%] Compiling...
> f951: internal comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117514
--- Comment #1 from Jordan <8e3g6jay6 at mozmail dot com> ---
Oh, very sorry. I forgot to include the traceback
vulkan_driver_select_physical_device.f9failed.
[ 20%] Compiling...
f951: internal compiler error: gfc_typename(): Undefined type
0x74
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117514
Bug ID: 117514
Summary: sizeof(c_null_ptr) or something?
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
Jordan <8e3g6jay6 at mozmail dot com> changed:
What|Removed |Added
Status|RESOLVED|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #18 from Jordan <8e3g6jay6 at mozmail dot com> ---
(In reply to Jordan from comment #17)
> (In reply to kargls from comment #16)
> > (In reply to Jordan from comment #15)
> > > I do not mean to burst your bubble, but Vulkan 1.1 releas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116668
Jordan <8e3g6jay6 at mozmail dot com> changed:
What|Removed |Added
Status|RESOLVED|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116668
Jordan <8e3g6jay6 at mozmail dot com> changed:
What|Removed |Added
Resolution|--- |WONTFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
Jordan <8e3g6jay6 at mozmail dot com> changed:
What|Removed |Added
Resolution|--- |WONTFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #15 from Jordan <8e3g6jay6 at mozmail dot com> ---
(In reply to Jerry DeLisle from comment #14)
> (In reply to anlauf from comment #9)
> --- snip ---
> > So do we want a limit close to
> >
> > 6.3.2.6 ... A statement shall not have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #3 from Jordan <8e3g6jay6 at mozmail dot com> ---
I tested this:
program main
use, intrinsic :: iso_c_binding
implicit none
integer ::
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_PROPERTIES_KHR = 1
end program mai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
Bug ID: 117381
Summary: -fmax-identifier-length= is completely ignored
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116828
--- Comment #4 from Jordan <8e3g6jay6 at mozmail dot com> ---
thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116828
--- Comment #2 from Jordan <8e3g6jay6 at mozmail dot com> ---
I have actually examined this further and it seems like it's managing to
perfectly overflow back to 0 somehow. I am not sure if there is supposed to be
some sort of error or any kind o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116828
--- Comment #1 from Jordan <8e3g6jay6 at mozmail dot com> ---
Here's a simplified version that does the same:
program oh_no
use, intrinsic :: iso_c_binding
implicit none
integer(c_int) :: w
w = 1
do
w = w + w
! IT'S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116828
Bug ID: 116828
Summary: Gfortran 14.0.1 thinks that [ 1 + 1 = 0 ]
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortra
20 matches
Mail list logo
