https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #21 from Jerry DeLisle ---
(In reply to Richard Biener from comment #20)
--- snip ---
>
> so you can instead do
>
> gfc_symbol_buffer the_buf;
>
> and have it behave like a char the_buf[GFC_MAX_SYMBOL_LEN] declaration.
>
> The au
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #20 from Richard Biener ---
It might be possible to use C++ to hide awkwardness of dynamic allocation and
still support a cheap stack-based allocation for small -fmax-identifier-length.
You can use
auto_vec buf;
buf.reserve_exact (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
Jerry DeLisle changed:
What|Removed |Added
Severity|normal |enhancement
Status|WAITING
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=117381
Jordan <8e3g6jay6 at mozmail dot com> changed:
What|Removed |Added
Resolution|--- |WONTFIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #16 from kargls at comcast dot net ---
(In reply to Jordan from comment #15)
> I do not mean to burst your bubble, but Vulkan 1.1 released in 2018 and
> ChatGPT came out in 2022 lol.
Snarky comments are a proven method to deter those
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 #14 from Jerry DeLisle ---
(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 more than one million characters.
>
> ?
This ridiculous number seems to be t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #12 from kargls at comcast dot net ---
(In reply to anlauf from comment #11)
> (In reply to kargls from comment #10)
> > (In reply to anlauf from comment #9)
> > > (In reply to kargls from comment #8)
> > > > One could set GFC_MAX_SYM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #10)
> (In reply to anlauf from comment #9)
> > (In reply to kargls from comment #8)
> > > One could set GFC_MAX_SYMBOL_LEN to a value larger than 63, but what
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #10 from kargls at comcast dot net ---
(In reply to anlauf from comment #9)
> (In reply to kargls from comment #8)
> > One could set GFC_MAX_SYMBOL_LEN to a value larger than 63, but what
> > value makes sense? (Note it will be less
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #8)
> One could set GFC_MAX_SYMBOL_LEN to a value larger than 63, but what
> value makes sense? (Note it will be less than 1, which is the
> longest statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #8 from kargls at comcast dot net ---
(In reply to Jerry DeLisle from comment #6)
> This begs the question whether we should support longer symbols as an
> extension.
This likely would require a big change to the frontend. There are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #7 from kargls at comcast dot net ---
(In reply to anlauf from comment #5)
> While Nvidia and flang seem to allow the sample code, even the latest
> Intel ifx 2025.0 rejects it:
>
> pr117381.f90(5): error #6439: This symbol has too m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #5 from anlauf at gcc dot gnu.org ---
While Nvidia and flang seem to allow the sample code, even the latest
Intel ifx 2025.0 rejects it:
pr117381.f90(5): error #6439: This symbol has too many characters.
[VK_STRUCTURE_TYPE_PHYSICAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
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
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-10-31
Status|UNCONFIR
22 matches
Mail list logo
