https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117354
--- Comment #11 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b39f62ff739e9ffea0e6485667f15b985f8cd63d
commit r15-4796-gb39f62ff739e9ffea0e6485667f15b985f8cd63d
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117365
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117371
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117373
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115700
--- Comment #12 from Paul Thomas ---
(In reply to GCC Commits from comment #11)
> The master branch has been updated by Paul Thomas :
>
> https://gcc.gnu.org/g:159fb203231c503418e7ab9f45282957e40cb195
>
> commit r15-4793-g159fb203231c503418e7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112459
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=117385
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
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=117350
--- Comment #21 from ak at gcc dot gnu.org ---
Thanks.
I'll see if this patch is enough:
diff --git a/gcc/tree.cc b/gcc/tree.cc
index b4c059d3b0db..92f99eaccd72 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -787,8 +787,9 @@ need_assembler_name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117245
--- Comment #9 from GCC Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:9eae9268e41463927c9383004e58708048ec379f
commit r15-4812-g9eae9268e41463927c9383004e58708048ec379f
Author: Martin Uecker
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117145
--- Comment #12 from GCC Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:9eae9268e41463927c9383004e58708048ec379f
commit r15-4812-g9eae9268e41463927c9383004e58708048ec379f
Author: Martin Uecker
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100420
--- Comment #3 from GCC Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:9eae9268e41463927c9383004e58708048ec379f
commit r15-4812-g9eae9268e41463927c9383004e58708048ec379f
Author: Martin Uecker
Date: T
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=38833
--- Comment #1 from Andrew Pinski ---
--enable-coverage has been there (and documented) since
r0-44516-g22aa533ee7d277 (which was in 2002, 7 years before this bug was
filed).
So the first part of this bug was already existing.
The second part o
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=31980
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19831
Sam James changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Keyword
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=31158
--- Comment #6 from Andrew Pinski ---
Looks fixed in GCC 9, Let me see if I can find the commit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57342
Bug 57342 depends on bug 31158, which changed state.
Bug 31158 Summary: wrong line number in warning: overflow in implicit constant
conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31158
What|Removed |Ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88375
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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=114175
--- Comment #64 from Sam James ---
I think the bug was kept open for other targets to check if they needed
adaptation.
jakub's guess in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175#c24 said:
> aarch64, alpha, arc, maybe arm, csky, maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117380
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115274
--- Comment #15 from Sam James ---
On the original with Qing's v3 patch, quoting output from bundled copy in
nodejs but it happens with upstream too:
```
../../deps/sqlite/sqlite3.c:35003:28: warning: ‘strlen’ reading 1 or more bytes
from a regi
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=100165
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117183
--- Comment #4 from GCC Commits ---
The master branch has been updated by Sam James :
https://gcc.gnu.org/g:2a4ee57b04398e54284e3d6b5ed4f8842ee26a5c
commit r15-4813-g2a4ee57b04398e54284e3d6b5ed4f8842ee26a5c
Author: Sam James
Date: Thu Oct 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117183
Sam James changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117183
Sam James changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from Sam James ---
Pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117183
Sam James changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108040
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494
Sam James changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|2023-04-13 00:00:00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31158
Andrew Pinski changed:
What|Removed |Added
Target Milestone|10.0|9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88375
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |9.0
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=117360
--- Comment #3 from Jeffrey A. Law ---
What's interesting is I did a bootstrap with ubsan a while back to chase down
this stuff. Could be something recently introduced or a path we didn't trigger
before. Regardless I'll case it down.
Yes, we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117350
--- Comment #17 from ak at gcc dot gnu.org ---
http://firstfloor.org/~andi/fbdata.afdo is the gcov file for the reproducer
above.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117375
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117363
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77686
Andrew Pinski changed:
What|Removed |Added
CC||Koen.Poppe at vandewiele dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117365
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101887
Simon Martin changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117093
Jennifer Schmitz changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jschmitz at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117176
--- Comment #13 from Sergei Trofimovich ---
The change fixed netpbm-11.8.0 build for me. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117360
--- Comment #4 from Martin Jambor ---
(In reply to Jeffrey A. Law from comment #3)
> What's interesting is I did a bootstrap with ubsan a while back to chase
> down this stuff. Could be something recently introduced or a path we didn't
> trigge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117350
--- Comment #19 from Andrew Pinski ---
(In reply to ak from comment #18)
> Okay I looked into need_assembler_name_p. For __ct function_decl it bails
> out due to
> I assume that means HAS_DECL_ASSEMBLER_NAME_P returns false.
HAS_DECL_ASSEMBLER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801
--- Comment #36 from Richard Earnshaw ---
I've been looking at this. I think the real problem is that trunc_int_for mode
is doing something incompatible with what the later code expects. We have
/* Canonicalize BImode to 0 and STORE_FLAG_VA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117384
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-10-31
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117375
--- Comment #7 from qinzhao at gcc dot gnu.org ---
The reason for the ICE is:
The destination of the code movement due to tree sinking might not be the
immediate destination block of the block in which the statement locates.
for example:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117350
--- Comment #16 from ak at gcc dot gnu.org ---
I'm not sure the revision in the subject is right. Given the reproduction in
gcc 13 it seems to me this is a latent bug that is just triggered by changes in
the bootstrapped input source. Strangely i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117350
--- Comment #18 from ak at gcc dot gnu.org ---
Okay I looked into need_assembler_name_p. For __ct function_decl it bails out
due to
784 /* If DECL already has its assembler name set, it does not need a
785 new one. */
786
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117358
Andrew Pinski changed:
What|Removed |Added
Summary|ICE: in execute_todo, at|[12/13/14/15 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117350
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117361
Sam James changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117385
Bug ID: 117385
Summary: Move phiopt away from doing a COND_EXPR with a
comparison as first operand
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175
Edwin Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117383
Bug ID: 117383
Summary: gcc relies on RISC-V vcompress instruction undefined
behaviour
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116783
Alex Coplan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63783
--- Comment #26 from John Paul Adrian Glaubitz ---
(In reply to Richard Biener from comment #25)
> Fixed I assume.
Yes, I just verified that the original reproducer does no longer trigger the
assertion both with GCC 14 and GCC 15.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117363
--- Comment #12 from Sergei Trofimovich ---
(In reply to Andrew Pinski from comment #11)
> Created attachment 59512 [details]
> Fixed up patch
That fixes `waybar-0.11.0` build for me. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117384
Bug ID: 117384
Summary: [15 regression] ICE when building gwenhywfar-5.10.1
(error: non-trivial conversion in ‘var_decl’)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115700
--- Comment #11 from GCC Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:159fb203231c503418e7ab9f45282957e40cb195
commit r15-4793-g159fb203231c503418e7ab9f45282957e40cb195
Author: Paul Thomas
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117380
Bug ID: 117380
Summary: ICE: tree check: expected class 'type', have
'exceptional' (error_mark) in get_unwidened, at
tree.cc:8019
Product: gcc
Version: 15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86878
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:646b24efaa50b149c12d0ae432999cb5a0cd12f2
commit r15-4797-g646b24efaa50b149c12d0ae432999cb5a0cd12f2
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117354
--- Comment #12 from Jakub Jelinek ---
Should be fixed now for 15.1+ so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
--- Comment #6 from Jeffrey A. Law ---
So my approach would be to note the insn number, then set a conditional
breakpoint in make_insn_raw (after it initializes INSN_UID in the new insn).
The condition would be insn->u2.insn_uid == or somethi
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=110137
--- Comment #19 from Jason Merrill ---
As I was suggesting on IRC, I think CALL_FROM_NEW_OR_DELETE_P already has the
semantics we want, we could also set it on direct calls when assuming sane op
new/delete. And maybe rename it to something like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #22 from Jason Merrill ---
But as Jonathan says in comment 10, the replaceable operator new is shared by
the whole program, so I don't see why we would need a per-call flag for the
global memory aliasing property; either the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #23 from Jakub Jelinek ---
I've just tried:
int i, j, k;
void *
foo ()
{
i = 1;
j = 2;
void *p = __builtin_operator_new (32);
j = 3;
k = i;
return p;
}
void *
bar ()
{
i = 1;
j = 2;
void *p = __builtin_malloc (32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #20 from Richard Biener ---
Whether a call clobbers or uses memory is controlled by fnspec these days
and a malloc attribute does _not_ indicate this. It works for malloc/free
because we make it so via the builtins in builtin_fnspec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117382
--- Comment #3 from Jonathan Wakely ---
[dcl.enum] p5:
Each enumeration also has an underlying type. The underlying type can be
explicitly specified using an enum-base. For a scoped enumeration type, the
underlying type is int if it is not expl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117384
Sam James changed:
What|Removed |Added
Keywords|needs-reduction |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117382
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #21 from Jason Merrill ---
(In reply to Richard Biener from comment #20)
> It still uses/clobbers global memory though.
Hmm, I guess that's a separate issue from being able to elide the calls
entirely, which is what CALL_FROM_NEW_OR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117384
--- Comment #4 from Andreas Schwab ---
s/unsigned/signed/ to make it fail the same with -funsigned-char.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106073
--- Comment #14 from GCC Commits ---
The master branch has been updated by Sam James :
https://gcc.gnu.org/g:df09173e355f30089b97090b19c095907242b35e
commit r15-4803-gdf09173e355f30089b97090b19c095907242b35e
Author: Sam James
Date: Thu Oct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #25 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #24)
> Well, to be precise, it would need to be a per-call property if we want to
> allow people to redefine those and don't use those call flags within the TUs
> whe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
--- Comment #38 from GCC Commits ---
The master branch has been updated by Sam James :
https://gcc.gnu.org/g:df09173e355f30089b97090b19c095907242b35e
commit r15-4803-gdf09173e355f30089b97090b19c095907242b35e
Author: Sam James
Date: Thu Oct 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #26 from rguenther at suse dot de ---
On Thu, 31 Oct 2024, jason at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
>
> --- Comment #25 from Jason Merrill ---
> (In reply to Jakub Jelinek from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117384
--- Comment #2 from Sam James ---
```
void a() {
char b[] = {
144, 128, 112, 96, 80, 64, 48, 32, 1, 2, 3, 4, 5, 6, 7, 8,
9, 24, 39, 54, 69, 84, 99, 114, 17, 34, 51, 68, 85, 102, 119, 136,
153, 136, 119, 102, 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117384
--- Comment #3 from Sam James ---
Works with -funsigned-char.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #28 from Jan Hubicka ---
We could make -fassume-sane-operator-new optimization attribute, but then we
would need to prevent inlining functions with insane operators to functions
with sane operators, or drop the sanity on caller.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117176
--- Comment #11 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:d2f9159cfe7ea904e6476cabefea0c6ac9532e29
commit r15-4802-gd2f9159cfe7ea904e6476cabefea0c6ac9532e29
Author: Tamar Christina
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #24 from Jakub Jelinek ---
(In reply to Jason Merrill from comment #22)
> But as Jonathan says in comment 10, the replaceable operator new is shared
> by the whole program, so I don't see why we would need a per-call flag for
> the g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #27 from Jan Hubicka ---
This is somewhat weird testcase which makes two allocations which compiler can
track as non-escaping and tests its ability to disambiguate them:
int test3(int *data)
{
int *val = new int;
*va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
--- Comment #29 from Jan Hubicka ---
For completeness note that we can also stick info into FUNCTION_DECLs (i.e. by
an attribute) to avoid flags pollution. Then it could be TU sensitive since
lto-symtab knows that in certain cases it should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576
Andrew Pinski changed:
What|Removed |Added
CC||sunsijie at buaa dot edu.cn
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117389
--- Comment #4 from Andrew Pinski ---
Actually it is a dup of bug 101367.
*** This bug has been marked as a duplicate of bug 101367 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101367
Andrew Pinski changed:
What|Removed |Added
CC||sunsijie at buaa dot edu.cn
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101367
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117389
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> Actually it is a dup of bug 101367.
And it describes what you found with lambda captures (of strings) to the tee
too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100272
Sam James changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117390
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117390
Bug ID: 117390
Summary: Error message for trying to call an constructor with
template arguments should be improved
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116668
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 #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
>
1 - 100 of 173 matches
Mail list logo
