When the ST_NONE case is taken, the function returns immediately. Not calling
pop_state causes a dangling pointer.
gcc/fortran/ChangeLog:
* parse.cc (parse_omp_dispatch): Add missing pop_state.
---
gcc/fortran/parse.cc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
Pushed to master as obvious. This should fix PR118714.
On 31/01/2025 11:46, Paul-Antoine Arras wrote:
When the ST_NONE case is taken, the function returns immediately. Not calling
pop_state causes a dangling pointer.
gcc/fortran/ChangeLog:
* parse.cc (parse_omp_dispatch): Add missing p
On 1/30/25 1:44 PM, Harald Anlauf wrote:
Dear all,
analyzing the the PR (by Gerhard) turned out to two slightly related
issues. The first one, where a variable in a COMMON block is falsely
resolved to a derived type declared in the host, leads to a false
freeing of the symbol, resulting in memo
Am 31.01.25 um 18:37 schrieb Jerry D:
On 1/30/25 1:44 PM, Harald Anlauf wrote:
Dear all,
analyzing the the PR (by Gerhard) turned out to two slightly related
issues. The first one, where a variable in a COMMON block is falsely
resolved to a derived type declared in the host, leads to a false
f
The Fortran front end was giving an ICE instead of a user-friendly
diagnostic when variants of a metadirective variant had different
statement associations. The particular test case reported in the issue
also involved invalid placement of the "omp end metadirective" which
was not being diagnosed e
Hi Jerry,
Am 30.01.25 um 21:50 schrieb Jerry D:
On 1/29/25 10:30 AM, Jerry D wrote:
Follow-up:
On 1/28/25 1:33 PM, Harald Anlauf wrote:
Jerry,
while I haven't read your actual patch yet, I think the testcase
is slightly incorrect. In fact, Intel, NAG, Nvidia and AMD flang
disagree with it.
On 1/31/25 11:30 AM, Harald Anlauf wrote:
Hi Jerry,
Am 30.01.25 um 21:50 schrieb Jerry D:
On 1/29/25 10:30 AM, Jerry D wrote:
Follow-up:
On 1/28/25 1:33 PM, Harald Anlauf wrote:
Jerry,
while I haven't read your actual patch yet, I think the testcase
is slightly incorrect. In fact, Intel, NA
