https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109206
--- Comment #2 from CVS Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:259bd768640328cc98647c5cf8b0d6dcfba6d4bf
commit r13-6772-g259bd768640328cc98647c5cf8b0d6dcfba6d4bf
Author: Paul Thomas
Date: Tue M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #17 from CVS Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:3a9caf7883103bc3a80dfc9e4797bb849b3c211c
commit r13-6771-g3a9caf7883103bc3a80dfc9e4797bb849b3c211c
Author: Paul Thomas
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223
--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> Why do you think it should work?
>
> R863 implicit-stmt is IMPLICIT implicit-spec-list
> or IMPLICIT NONE [ ( [ implicit-none-s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43144
--- Comment #2 from Alisdair Meredith ---
gcc 4.5 and later correctly report errors, as the language specification for
rvalue and forwarding references changed between 4.4 and 4.5.
I'm not sure what ADL bug I thought I was hitting, but with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105325
Michael Meissner changed:
What|Removed |Added
Assignee|acsawdey at gcc dot gnu.org|meissner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109226
urbanjost at comcast dot net changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223
--- Comment #1 from urbanjost at comcast dot net ---
*** Bug 109226 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109226
Bug ID: 109226
Summary: parameters for a type on IMPLICIT do not work. For
example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails
Product: gcc
Version: 12.2.0
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109225
bagel ming changed:
What|Removed |Added
CC||bagelming at outlook dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109225
Bug ID: 109225
Summary: -Wanalyzer-null-dereference false negative with *c =
404
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64758
Andrew Pinski changed:
What|Removed |Added
CC||barry.revzin at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109222
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109222
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109224
Bug ID: 109224
Summary: Wmismatched-new-delete false positive with corotuines
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223
Bug ID: 109223
Summary: parameters for a type on IMPLICIT do not work. For
example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails
Product: gcc
Version: 12.2.0
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109222
Bug ID: 109222
Summary: Confusing error for declaring an enum class with
unknown type
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109221
--- Comment #4 from Andrew Pinski ---
With -ffast-math -mfpmath=387,sse (or -mavx512f instead of -mfpmath=387 as
there is a avx512f instruction too) added, ldexp gets inlined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109221
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #3 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109221
--- Comment #2 from Witold Baryluk ---
Interesting enough, GDC 10.2 does inline `poly` instantiation with all the
constants.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109221
--- Comment #1 from Witold Baryluk ---
PS. LDC 1.23.0 - 1.32.0 produce optimal code. LDC 1.22.0 a bit worse (due to
use of x87 codegen), and 1.21 and older fail to inline `ldexp`, but still
inline `poly` and `floor` perfectly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109221
Bug ID: 109221
Summary: std.math.floor, core.math.ldexp, std.math.poly poor
inlining
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50387
--- Comment #2 from Andrew Pinski ---
Simplified testcase:
```
#define GET(H) _Pragma("")
#include GET(stdio.h)
```
Both MSVC and clang are able to handle this.
ICC rejects it for the same reason as GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44173
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109205
--- Comment #3 from Jonathan Wakely ---
Huh, but that causes a test to FAIL with -D_GLIBCXX_DEBUG
FAIL: 23_containers/vector/59829.cc (test for excess errors)
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_vecto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44881
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2010-07-24 18:53:22 |2023-3-20
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44176
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-03-21
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42161
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed|2009-12-0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43144
--- Comment #1 from Andrew Pinski ---
Starting GCC 4.5.x we get the following error message first:
: In function 'typename std::remove_reference<_Tp>::type&&
std0x::move(T&&) [with T = int&, typename std::remove_reference<_Tp>::type =
int]':
:36:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109203
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #6 from Jian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38274
--- Comment #6 from Andrew Pinski ---
Note if you want to detect more buffer overruns you should try
-fsanitize=address
. Valgrind will also detect more too.
BUT note none of these are 100% either because they only have a limited redzone
and val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38274
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109181
--- Comment #4 from Andrew Pinski ---
(In reply to Patrick Palka from comment #3)
> A workaround is to just remove the unneeded 'template' after the :: in this
> case. Or is there an example where the template keyword is needed that we
> incorr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109181
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31787
--- Comment #5 from Andrew Pinski ---
Fixed in RTEMS by
https://devel.rtems.org/changeset/008171099d817f4745ab55a68121d5dba7b66181/rtems
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31787
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31787
Andrew Pinski changed:
What|Removed |Added
Keywords||inline-asm
--- Comment #3 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31089
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2007-03-19 09:14:51 |2023-3-20
--- Comment #2 from Andrew Pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109220
Bug ID: 109220
Summary: analyzer doesn't complain about unrecognized state
machines with -fanalyzer-checker=NAME
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7088
Andrew Pinski changed:
What|Removed |Added
Assignee|neroden at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #16 from Jürgen Reuter ---
(In reply to Paul Thomas from comment #14)
> For the record, the fix is:
>
> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> index 1d973d12ff1..1a03e458d99 100644
> --- a/gcc/fortran/resolve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
David Malcolm changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109205
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109216
--- Comment #2 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:6c2b28e43205b7b0cef9ac8504621c4cd0ccbde7
commit r13-6766-g6c2b28e43205b7b0cef9ac8504621c4cd0ccbde7
Author: Harald Anlauf
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109217
--- Comment #2 from Jonathan Wakely ---
So a dup of Bug 7516 then?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109199
David Malcolm changed:
What|Removed |Added
Summary|GCC Static Analyzer |GCC Static Analyzer
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99036
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109159
Marek Polacek changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109191
--- Comment #2 from David Malcolm ---
It is valid in the embedded space to do things like
*(SOME_CONSTANT_ADDRESS) = SOME_VALUE;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109159
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:a226590fefb35ed66adf73d85cefe49048a78ab8
commit r13-6765-ga226590fefb35ed66adf73d85cefe49048a78ab8
Author: Marek Polacek
Date: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109197
David Malcolm changed:
What|Removed |Added
Summary|GCC Static Analyzer does|Analyzer gets confused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109196
David Malcolm changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99036
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99036
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||volker.weissmann at gmx dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109211
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109195
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940
--- Comment #3 from David Malcolm ---
*** Bug 109195 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940
--- Comment #2 from David Malcolm ---
*** Bug 109194 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109194
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104940
David Malcolm changed:
What|Removed |Added
CC||geoffreydgr at icloud dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109193
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109219
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-03-20
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109219
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.3
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109194
--- Comment #1 from David Malcolm ---
Well, strictly speaking not all of these are true; consider
a == INT_MAX
b == INT_MAX - 1
Then a > b, but:
* a + 1 is, I believe, undefined, but we may want to treat it as INT_MIN
* b + 1 is INT_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109219
Bug ID: 109219
Summary: csmith: ice in vect_slp_analyze_node_operations_1, at
tree-vect-slp.cc:5954
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109191
--- Comment #1 from David Malcolm ---
GCC does emit a -Wint-to-pointer-cast warning on this code, for the int to void
* conversion.
Is this reduced from a real-world example, or just synthesized by hand?
I suppose in theory the analyzer could:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109192
--- Comment #7 from Andrew Macleod ---
Created attachment 54716
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54716&action=edit
proposed patch
This is due to the latter part of the specified patch. We normally terminate
outgoing range c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99669
David Malcolm changed:
What|Removed |Added
CC||geoffreydgr at icloud dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109201
David Malcolm changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109200
David Malcolm changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109201
--- Comment #2 from David Malcolm ---
*** Bug 109200 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109201
--- Comment #1 from David Malcolm ---
The division by zero warning on:
if ((d.b = 1) / 0)
is from -Wdiv-by-zero, which isn't from the analyzer (
https://godbolt.org/z/433PhKhvM )
The analyzer currently only implements -Wanalyzer-tainted-divi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109170
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Summary|New glibc warni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109175
--- Comment #4 from Andrew Pinski ---
auto in = AllocateAligned(padded);
The pointer returned here could be a nullptr
The warning is due to jump threading though.
AllocateAligned calls AllocateAlignedItems
Which could return nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109216
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-03-20
Keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109164
--- Comment #7 from Jakub Jelinek ---
Fixed on the trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109164
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0a846340b99675d57fc2f2923a0412134eed09d3
commit r13-6764-g0a846340b99675d57fc2f2923a0412134eed09d3
Author: Jakub Jelinek
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109215
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109067
--- Comment #2 from CVS Commits ---
The master branch has been updated by Michael Meissner :
https://gcc.gnu.org/g:c67f312d20e15e5aa18c587693b4ab7e131596c1
commit r13-6763-gc67f312d20e15e5aa18c587693b4ab7e131596c1
Author: Michael Meissner
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109211
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-03-20
Keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109205
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109205
--- Comment #1 from Andrew Pinski ---
So the IR looks like:
_4 = MEM[(const struct vector *)v_3(D)].D.25711._M_impl.D.25018._M_finish;
_6 = MEM[(const struct vector *)v_3(D)].D.25711._M_impl.D.25018._M_start;
_7 = _4 - _6;
_8 = (long uns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109208
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #15 from anlauf at gcc dot gnu.org ---
JFTR: Nvidia also doesn't like the reproducer:
NVFORTRAN-S-1056-MODULE prefix is only allowed for subprograms that were
declared as separate module procedures (pr109209.f90: 63)
0 inform, 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109213
--- Comment #4 from Andrew Pinski ---
If you force m to be always_inline, we are back to GCC 12 code generation.
I don't think there is anything GCC can do with differently; the heurstics are
not tuned for these small "benchmark" functions eith
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #14 from Paul Thomas ---
For the record, the fix is:
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 1d973d12ff1..1a03e458d99 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -11760,6 +11760,7 @
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109186
--- Comment #6 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:4410a08b80cc40342eeaa5b6af824cd4352b218c
commit r13-6762-g4410a08b80cc40342eeaa5b6af824cd4352b218c
Author: Harald Anlauf
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #13 from Paul Thomas ---
(In reply to Tobias Burnus from comment #12)
> I bet that's due to the finalization
> commit r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee
> but I have not verified.
>
...snip...
See my reply above.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109215
--- Comment #5 from Jakub Jelinek ---
This is complete mess.
/* Describes a "special" array member for a COMPONENT_REF. */
enum struct special_array_member
{
none, /* Not a special array member. */
int_0, /* Interior array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109213
--- Comment #3 from Andrew Pinski ---
In fact if you change main to:
int main() {
int p[10];
m();
if (!i()) {
int *q = &p[0];
for (; g;)
b(e == q);
}
}
GCC 12 also does not do the inlining.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109213
--- Comment #2 from Andrew Pinski ---
Basically just unluckness ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109213
--- Comment #1 from Andrew Pinski ---
The difference is due to inlining of m into main.
The reason for the difference of inlining is due to removal of:
p = {};
statement from main in dse which changes the overall cost of the TU ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109217
--- Comment #1 from Stas Sergeev ---
So as #7516 suggests, it is now indeed
rejected. :(
And at the same time clang has no problem
with that combination of options.
Please make that a valid option combination
again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109218
--- Comment #1 from Tobias Burnus ---
>From Paul Thomas from bug 109208 comment #11:
> NAG Fortran Compiler Release 7.1(Hanzomon) Build 7115
> Error: pr109209.f90, line 63: Type-bound procedure T3_SET_EXPAND must be a
> module procedure or exter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #12 from Tobias Burnus ---
I bet that's due to the finalization
commit r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee
but I have not verified.
(In reply to Jürgen Reuter from comment #10)
> Thanks for checking, Tobias. Are you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109215
--- Comment #4 from Jakub Jelinek ---
Slightly simplified -O2 -Wall:
struct S {};
struct T { struct S s[3]; struct S t; };
void bar (struct S *);
void
foo (struct T *t)
{
for (int i = 0; i < 3; i++)
bar (&t->s[i]);
}
On:
void
baz (struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
Paul Thomas changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109218
Bug ID: 109218
Summary: "MODULE SUBROUTINE" wrongly accepted where MODULE
prefix is not permitted.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: acc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109217
Bug ID: 109217
Summary: failure statically linking shared lib
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #10 from Jürgen Reuter ---
(In reply to Tobias Burnus from comment #8)
> The debugger shows for the example in comment 4 for the line
>
>69 | history_new(1:s) = res_set%history(1:s)
>
> the following expression:
>
> (gdb)
1 - 100 of 201 matches
Mail list logo
