https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109979
Bug ID: 109979
Summary: [12 Regression] -Wformat-overflow false positive for
%d and non-basic expression
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109979
--- Comment #1 from Andrew Pinski ---
The warning should happen for both ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109979
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Summary|[12 Regre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109979
--- Comment #3 from Andrew Pinski ---
Note there is no warning if you use -fwrapv which is what I expected as the
range of e-1 becomes the whole range because overflow becomes defined as
wrapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109979
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109980
Bug ID: 109980
Summary: Bogus Wstringop-overflow and Wstringop-overread
warnings when attribute `access` is applied to struct
arg
Product: gcc
Version: 13.1.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109979
--- Comment #5 from Vincent Lefèvre ---
(In reply to Andrew Pinski from comment #1)
> The warning should happen for both ...
OK (as the documentation says "[...] that might overflow the destination
buffer).
(In reply to Richard Biener from com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109981
Bug ID: 109981
Summary: ICE encountered while generating header units in the
given sequence in a script
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83002
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
Bug ID: 109982
Summary: csmith: x86_64: znver1 issues
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109976
--- Comment #2 from Jonathan Wakely ---
(In reply to Ed Catmur from comment #0)
> This appears to be caused by bug 109975, but I'm filing separately since it
> may be possible to fix in library.
Maybe we can skip some of the debug checks durin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907
--- Comment #20 from Georg-Johann Lay ---
Here is a testcase similar to the one from PR55181, where the first test is for
the sign bit:
unsigned char lfsr32_mpp_sign (unsigned long number)
{
unsigned char b = 0;
if (number & (1UL << 31)) b-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
Bug ID: 109983
Summary: [12/13/14 regression] Wireshark compilation hangs with
-O2 -fipa-pta
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
--- Comment #1 from Sam James ---
I let perf spin for a while and got this w/ 13:
```
$ perf record gcc-13 -O2 -fipa-pta -c packet-rnsap.c.i
[^C'd after ~2 minutes]
$ perf report
43.18% cc1 cc1 [.] bitmap_ior_int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
Sam James changed:
What|Removed |Added
Keywords||compile-time-hog
--- Comment #2 from Sam Ja
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109984
Bug ID: 109984
Summary: FAIL: insn-modes.h: No such file or directory
(x86_64-apple-darwin22.4.0)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
Paul Thomas changed:
What|Removed |Added
Blocks||87477
--- Comment #8 from Paul Thomas --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
--- Comment #1 from Uroš Bizjak ---
Also fails with "-mtune=znver1 -mavx":
Program received signal SIGSEGV, Segmentation fault.
0x004048ef in func_21 (p_22=0x41b330 , p_23=0, p_24=8) at
runData/keep/in.11.c:597
597 in runData/keep/i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
--- Comment #2 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #1)
> (gdb) p/x $rdx
> $3 = 0x41a824
>
> Unaligned access.
Actually, just a garbage value.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
--- Comment #9 from Paul Thomas ---
By the way, the patch regtests OK
Do you want to do the honours or shall I?
I think that this rates as an 'obvious' fix.
Paul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
Sergei Trofimovich changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
--- Comment #4 from Sam James ---
I know what the option does, but:
1. It's substantially slower in 12/13/14, with or without checking. If that's
expected, that's fine, but someone has to say if it is.
2. With default checking (=release) on 12.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
--- Comment #5 from Sergei Trofimovich ---
> For me it finishes in 3 minutes on gcc-14.
I'll take it back. It does not finish for me in 10 minutes on gcc-14. Don't
know where I picked the number.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907
--- Comment #21 from Georg-Johann Lay ---
One more test:
unsigned char lfsr32_mpp_ge0 (unsigned long number)
{
unsigned char b = 0;
if (number >= 0) b--;
if (number & (1UL << 29)) b++;
if (number & (1UL << 13)) b++;
return b;
}
with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109985
Bug ID: 109985
Summary: __builtin_prefetch ignored by GCC 12/13
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109986
Bug ID: 109986
Summary: missing fold (~a | b) ^ a => ~(a & b)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109986
--- Comment #1 from Ivan Sorokin ---
(In reply to Ivan Sorokin from comment #0)
> int foo(int a, int b)
> {
> return (~a | b) ^ a;
> }
>
> This can be optimized to `return ~(a | b);`. This transformation is done by
> LLVM, but not by GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #41 from Alexander Klepikov
---
> > It looks like with optimization enabled it converts bitwise AND to right
> > shift and then optimizes again. But SH4 has 'shad' and 'shad' can be
> > optimized to 'tst'. And SH2E has libcall instea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #13 from Pascal Cuoq ---
@Martin
I completely agree with comment 12, however about the last paragraph, I would
like to point out that for purposes of memcpy'ing to or from such a struct with
initialized FAM, it is enough to recommen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109987
Bug ID: 109987
Summary: ICE in in rs6000_emit_le_vsx_store on ppc64le with
-Ofast -mno-power8-vector
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109973
--- Comment #4 from Benji Smith ---
Just as follow-up, I also tested the same code with
_mm_and_si128/_mm_testc_si128 on SSE4.1, and the same issue repros (via `gcc
-O1 -msse4.1`):
#include
int do_stuff(__m128i Y0, __m128i Y1, __m128i X2) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109988
Bug ID: 109988
Summary: -iwithprefix doesn't add folder to end of search list
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109840
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109988
--- Comment #1 from Ivan Lazaric ---
In `gcc/c-family/c-opts.cc`:
```
case OPT_iwithprefix:
add_prefixed_path (arg, INC_SYSTEM);
break;
```
Should `INC_SYSTEM` actually be `INC_AFTER` ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #10 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811
--- Comment #11 from Jakub Jelinek ---
DWARF unwinding works properly, just in Linux kernel they decided they don't
want it in the kernel (I think they had some non-perfect implementation in the
past and it got removed).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109989
Bug ID: 109989
Summary: RISC-V: Missing sign extension with int to float
conversion with 64bit soft floats
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60749
Siarhei Volkau changed:
What|Removed |Added
CC||lis8215 at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
Bug ID: 109990
Summary: [12 Regression] Bogus -Wuse-after-free warning after
realloc
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
--- Comment #1 from Andrew Pinski ---
```
char *new_pool = (char *) realloc (string_space, new_size);
if (new_pool == ((void *)0))
goto out;
if (__builtin_expect (string_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> ```
>
> char *new_pool = (char *) realloc (string_space, new_size);
> if (new_pool == ((void *)0))
> got
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991
Bug ID: 109991
Summary: stack-use-after-scope
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98675
Andrew Pinski changed:
What|Removed |Added
CC||igkper at gmail dot com
--- Comment #6 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 109991, which changed state.
Bug 109991 Summary: stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109986
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907
--- Comment #22 from Andrew Pinski ---
(In reply to Georg-Johann Lay from comment #20)
> What then happens is:
>
> expr.cc::do_store_flag()
> expmed.cc::emit_store_flag_force()
> expmed.cc::emit_store_flag()
> expmed.cc::emit_store_flag_1()
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
--- Comment #3 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #1)
> Also fails with "-mtune=znver1 -mavx":
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x004048ef in func_21 (p_22=0x41b330 , p_23=0, p_24=8) at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109992
Bug ID: 109992
Summary: Addition/subtraction to the last bitfield of a struct
can be optimized
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109992
--- Comment #1 from Andrew Pinski ---
As an aside: it is funny how x86 does not have a bits insert instruction yet
(while almost all RISC targets have that now).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109992
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Component|rtl-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109992
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907
--- Comment #23 from Georg-Johann Lay ---
Thank you so much for looking into this.
For the test case from comment #21 though, the problem is somewhere in tree
optimizations.
> unsigned char lfsr32_mpp_ge0 (unsigned long number)
> {
> unsigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
Jakub Jelinek changed:
What|Removed |Added
Attachment #55151|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #51 from Jakub Jelinek ---
Note, I've only tested it so far on
_BitInt(256) a = 0x1234ab461289cdab8d111007b461289cdab8d1wb;
_BitInt(256) b = 0x2385eabcd072311074bcaa385eabcd07111007b46128wb;
_BitInt(384) c = (_BitInt(384)) 0x1234ab46
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109993
Bug ID: 109993
Summary: std::regex("\\a", std::regex::basic) does not diagnose
invalid BRE
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109956
--- Comment #14 from Martin Uecker ---
Maybe.
On the other hand, I wonder whether a struct with FAM should not rather always
have the same size, and alignment, and representation as the corresponding
struct with a conventional array. This wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
--- Comment #4 from David Binderman ---
Original git range was 123 commits.
Current bisect range is g:89ba8366fe12fd2d .. g:23be9d78f4bcd773,
which is 31 commits.
Trying 5b30e9bc211fede0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
--- Comment #4 from Bruno Haible ---
> >
> > char *new_pool = (char *) realloc (string_space,
> > new_size);
> > if (new_pool == ((void *)0))
> > goto out;
> > if (__bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109994
Bug ID: 109994
Summary: Issue a diagnostic when a C++ file defines a macro
that hides a keyword
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: diagno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109994
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109985
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
--- Comment #5 from Bruno Haible ---
Created attachment 55170
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55170&action=edit
test case bar2.c
Find attached a modified test case. I changed the code to
map[i].al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
--- Comment #6 from Andrew Pinski ---
(In reply to Bruno Haible from comment #4)
> That is the only way of keeping track of pointers _into_ the string_space
> area, when it is reallocated. How else would you want to do it?
You could use intptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109994
--- Comment #1 from Andrew Pinski ---
There are definitly testcases in GCC's testsuite which does this all the time.
#define int ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109994
--- Comment #2 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #1)
> There are definitly testcases in GCC's testsuite which does this all the
> time.
> #define int ...
Yeah, it shouldn't be in -Wall, and it's not a required dia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
--- Comment #5 from David Binderman ---
Current git range is g:193fccaa5c3525e9 .. g:5b30e9bc211fede0,
which is 8 commits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109994
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
--- Comment #6 from David Binderman ---
This commit looks highly likely:
commit eef81eefcdc2a58111e50eb2162ea1f5becc8004
Author: Jan Hubicka
Date: Thu Dec 22 10:55:46 2022 +0100
Zen4 tuning part 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109995
Bug ID: 109995
Summary: Bogus warning about __builtin_memset, from
-Wstringop-overflow
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109995
--- Comment #1 from Andrew Pinski ---
do *++p = c; while (--n > 0);
is turned into memset during optimizations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876
--- Comment #10 from Marek Polacek ---
So I have
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -27969,6 +27969,13 @@ value_dependent_expression_p (tree expression)
else if (TYPE_REF_P (TREE_TYPE (expression)))
/* FIXME cp_finish_decl does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #52 from Jakub Jelinek ---
(In reply to H.J. Lu from comment #14)
> (In reply to jos...@codesourcery.com from comment #13)
> > https://gitlab.com/x86-psABIs/i386-ABI/-/issues/5 to request such an ABI
> > for 32-bit x86. I don't kno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109985
Christian Mazakas changed:
What|Removed |Added
CC||christian.mazakas at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109985
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
David Binderman changed:
What|Removed |Added
CC||jh at suse dot cz
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109984
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109985
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109988
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-05-26
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #42 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #41)
>
> Thank you! I have an idea. If it's impossible to defer initial optimization,
> maybe it's possible to emit some intermediate insn and catch it and optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109996
Bug ID: 109996
Summary: csmith: -O2 -fno-strict-aliasing causing run time
trouble
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109997
Bug ID: 109997
Summary: __is_assignable(int, IncompleteType) should be
rejected
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71579
--- Comment #25 from Jonathan Wakely ---
Some missing completeness checks:
std::assignable
We don't enforce precondition that both types are complete types, cv void, or
arrays of unknown bound. Filed as PR c++/109997
std::common_type
Our impl i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876
--- Comment #11 from Marek Polacek ---
We never instantiated fnc because mark_used checks
/* Check this too in case we're within instantiate_non_dependent_expr. */
if (DECL_TEMPLATE_INFO (decl)
&& uses_template_parms (DECL_TI_ARGS (d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
--- Comment #6 from Sergei Trofimovich ---
Created attachment 55174
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55174&action=edit
packet-rnsap-shrunk-slightly.c.i.xz
packet-rnsap-shrunk-slightly.c.i.xz is a slightly shrunk version of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109997
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Last reco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109998
Bug ID: 109998
Summary: [OpenMP] TR12/5.0/5.1 - permit structure elements with
'!$OMP ALLOCATORS' (and !$OMP ALLOCATE)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
Bug ID: 10
Summary: [OpenMP] Bogus error message: talks about '"#pragma
omp" clause' instead of '"target" clause
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
--- Comment #1 from Andrew Pinski ---
: In function 'test_allocate_on_device':
:27:43: error: expected '#pragma omp' clause before 'uses_allocators'
27 | #pragma omp target map(tofrom: errors, A)
uses_allocators(omp_default_mem_alloc)
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991
--- Comment #3 from igk ---
(In reply to Andrew Pinski from comment #2)
> Dup of bug 98675.
>
> *** This bug has been marked as a duplicate of bug 98675 ***
Thanks for looking into this. I haven't quite understood though.
I'm trying to see i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991
--- Comment #4 from Andrew Pinski ---
(In reply to igk from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > Dup of bug 98675.
> >
> > *** This bug has been marked as a duplicate of bug 98675 ***
>
> Thanks for looking into this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
--- Comment #7 from Sergei Trofimovich ---
Original packet-rnsap.c.i.xz takes 27 minutes to compile for me.
The hack below cuts this time down to 9 minutes (slashes 60% of runtime).
The considerable amount of time is spent looking up the bitm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109983
--- Comment #8 from Andrew Pinski ---
(In reply to Sergei Trofimovich from comment #7)
> Original packet-rnsap.c.i.xz takes 27 minutes to compile for me.
>
> The hack below cuts this time down to 9 minutes (slashes 60% of runtime).
Or maybe i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109991
--- Comment #5 from igk ---
OK, becoming clearer, thanks. I'm just hoping for this to be diagnosed in some
way. IIUC basically GCC doesn't diagnose the UB so it proceeds with constexpr
eval just because it can, or so it thinks, and in the proces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11
Bug ID: 11
Summary: GCC should implement
exclude_from_explicit_instantiation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109982
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
1 - 100 of 135 matches
Mail list logo
