https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118511
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118534
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=118534
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |15.0
Priority|P3
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
// { dg-do compile { target c++14 } }
// { dg-options "" }
template
constexpr bool
foo ()
{
T x[160] = {
#embed __FILE__
|1
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Created attachment 60192
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60192&acti
at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Created attachment 60191
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60191&action=edit
gcc15-pr118528.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118532
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
// { dg-do compile { target c++20 } }
struct S {
S (int, int, int);
#define I8 int, int, int, int, int, int, int, int
#define I64 I8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118528
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2025-01-17
Ever confirmed|0
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
// { dg-do compile { target c++20 } }
template
struct E { T t[130][2]; };
E e1 {
#embed __FILE__ limit (260)
};
template
struct F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118522
--- Comment #5 from Jakub Jelinek ---
Fixed on the trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118509
--- Comment #3 from Jakub Jelinek ---
Created attachment 60182
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60182&action=edit
pr118509.ii
Somewhat reduced.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118524
--- Comment #5 from Jakub Jelinek ---
Filter -> Directives is filtering .base64 out but not .string, guess somebody
should file an issue against compiler explorer and ask that to be tweaked.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118524
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118522
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=118522
Jakub Jelinek changed:
What|Removed |Added
Component|middle-end |tree-optimization
--- Comment #1 from J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118514
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118519
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
||jakub at gcc dot gnu.org,
||mpolacek at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Started with r9-3807-g5d9a0e3b99e31a2167f6b6ab2473feb58f7c77e8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118509
--- Comment #2 from Jakub Jelinek ---
Trying to reduce it now...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118513
--- Comment #3 from Jakub Jelinek ---
Or of course if something like that isn't appropriate for all copy_linkage uses
(other than structured bindings it is used for guard variables I think), then
cp_finish_decomp could do that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118513
--- Comment #2 from Jakub Jelinek ---
--- gcc/cp/decl2.cc.jj 2025-01-16 13:34:29.719360710 +0100
+++ gcc/cp/decl2.cc 2025-01-16 14:27:54.095464791 +0100
@@ -3656,6 +3656,8 @@ copy_linkage (tree guard, tree decl)
comdat_linkage (guar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118513
--- Comment #1 from Jakub Jelinek ---
Note, on the structured binding base VAR_DECL, DECL_INTERFACE_KNOWN has been
set in
#0 constrain_visibility (decl=, visibility=4,
tmpl=false) at ../../gcc/cp/decl2.cc:2815
#1 0x005962ad in determin
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
--- gcc/testsuite/g++.dg/modules/decomp-3_a.H.jj2025-01-16
13:43:36.492879734 +0100
+++ gcc/testsuite/g++.dg/modules/decomp-3_a.H 2025
||2025-01-16
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Jakub Jelinek ---
Created attachment 60171
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60171&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118511
Jakub Jelinek changed:
What|Removed |Added
Target||s390x-linux
Target Milestone|---
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
s390-tools stage3.c has
static inline void __attribute__((noreturn)) start_kernel(void)
{
struct psw_t *psw = &(*((struct _lowcore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118430
Jakub Jelinek changed:
What|Removed |Added
Summary|[14/15 Regression] tail |[14 Regression] tail call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118400
--- Comment #10 from Jakub Jelinek ---
Please ignore the above comment, that was meant for a different PR.
This surely should be backported to 14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118400
Jakub Jelinek changed:
What|Removed |Added
Summary|[14/15 Regression] memory |[14 Regression] memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118497
--- Comment #1 from Jakub Jelinek ---
The reason this has been reported is that golang cgo has some weird code to
rewrite @GOT references which can deal with R_386_GOT32{,X} relocations only in
very limited subset of instructions, just movl symb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118497
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |15.0
Target|
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
Since r15-1619-g3b9b8d6cfdf59337f4b7ce10ce92a98044b2657b we emit one
instruction longer code for -O2 -m32 -fpic
extern void crosscall2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118496
--- Comment #2 from Jakub Jelinek ---
Unrolling is intentionally implemented using ANNOTATE_EXPR
annot_expr_unroll_kind.
So you need at least -O1 to see it in action.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118390
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118278
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118124
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118387
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116068
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118478
--- Comment #4 from Jakub Jelinek ---
(In reply to Tobias Burnus from comment #3)
> Thus, if 'firstprivate' is not on target, we have to use the
> C++ copy constructor and Fortran defined assignments.
Unless you have a proof, I think we already
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118478
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116068
--- Comment #6 from Jakub Jelinek ---
No, it uses a counter. So
bitmap_obstack_initialize (NULL);
bitmap_obstack_initialize (NULL);
...
bitmap_obstack_release (NULL);
bitmap_obstack_release (NULL);
does nothing in the inner calls except for inc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118400
--- Comment #7 from Jakub Jelinek ---
(In reply to rguent...@suse.de from comment #6)
> Maybe use
>
>m_vec->truncate (0);
>return;
>
> for simplicity?
Then I'll have to retest ;)
But I agree it is simpler that way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118400
--- Comment #5 from Jakub Jelinek ---
So I think we want
2025-01-14 Jakub Jelinek
PR ipa/118400
* vec.h (vec::release): Call vec_destruct
in the using_auto_storage () case.
--- gcc/vec.h.jj2025-01-02 11:23:13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118400
--- Comment #4 from Jakub Jelinek ---
This looks like a serious vec.h bug to me.
avals->m_known_value_ranges member is auto_vec.
ipa-fnsummary.cc does on that
if (!avals->m_known_value_ranges.length ())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118477
--- Comment #2 from Jakub Jelinek ---
Or
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673428.html
Both should work.
||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Started with r14-2121-g3c52dff792878306515056ecd94c8aa909f388fb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118430
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=116068
--- Comment #4 from Jakub Jelinek ---
Created attachment 60152
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60152&action=edit
gcc15-pr116068.patch
Full untested patch I'm going to test tonight then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118430
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
,
||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
It is clearly mixing up coroutines with range for:
for (const QString &displayName :
m_displays.knownDisplayNamesWithMissingData()) {
co_await queryAndInsertDisplay
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117231
--- Comment #9 from Jakub Jelinek ---
(In reply to Iain Sandoe from comment #8)
> (In reply to Jakub Jelinek from comment #7)
> > The last progress I see is Jason's patch review comments in
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-Dece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116068
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117231
--- Comment #7 from Jakub Jelinek ---
The last progress I see is Jason's patch review comments in
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671258.html
Iain, any progress since then? This is a P1 caused by my patch, so if there is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118403
--- Comment #10 from Jakub Jelinek ---
(In reply to Stephen Hemminger from comment #0)
> My understanding is that both should be equivalent.
> Reference C99 Standard 6.7.8.21:
>
> If there are fewer initializers in a brace-enclosed li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118403
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118456
--- Comment #3 from Jakub Jelinek ---
With -Wtautological-compare it even incorrectly warns:
./cc1 -quiet -O2 auu.c -Wtautological-compare; gcc -o auu{,.s}; ./auu
auu.c: In function ‘foo’:
auu.c:6:43: warning: comparison is always 0 [-Wtautologi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118456
--- Comment #2 from Jakub Jelinek ---
I meant to write that r15-6866 doesn't fix that, even r15-6868 fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118456
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
struct S { unsigned long long o; unsigned short a, b; } s;
__attribute__((noipa)) int
foo (void)
{
return ((unsigned char) s.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118408
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118408
--- Comment #7 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to TC from comment #0)
> - some programs consistently using the new ABI would get two identical
> definitions of _Scanner member functions, but that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116030
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98142
--- Comment #15 from Jakub Jelinek ---
BTW, if we implement an attribute for this, we should also add -fsanitize=enum
support for it, so that we diagnose whenever one loads a value which is not
named.
clang clearly doesn't implement that, so usin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118362
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118415
--- Comment #5 from Jakub Jelinek ---
Anyway, if we don't go the output_constant_def way, we'd need to change the
name (see above patch), make it public at least if target supports hidden
visibility, set DECL_VISIBILITY{,_SPECIFICIED}, use DECL_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118415
--- Comment #4 from Jakub Jelinek ---
(In reply to Jeffrey A. Law from comment #3)
> Using output_constant_def didn't even cross my mind.
>
> I don't recall the TREE_PUBLIC part of the change, though obviously at least
> part of the goal here w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117997
--- Comment #13 from Jakub Jelinek ---
Note, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118415#c2
patch fixes this by using section anchors. Which doesn't mean the linker isn't
buggy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118415
--- Comment #2 from Jakub Jelinek ---
Created attachment 60113
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60113&action=edit
gcc15-pr118415.patch
Though I wonder why we just don't call output_constant_def, that will simplify
it and wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118415
--- Comment #1 from Jakub Jelinek ---
Minimal patch could be
--- gcc/expr.cc.jj 2025-01-08 10:05:24.498994763 +0100
+++ gcc/expr.cc 2025-01-11 13:31:34.608998939 +0100
@@ -14304,12 +14304,17 @@ generate_crc_table (unsigned HOST_WIDE_I
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118415
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2025-01-11
Status|UNCONFIRM
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
unsigned char crc_table_for_crc_8_polynomial_0x7[2] = { 0xff, 0xff };
static unsigned char
foo (unsigned char byte, unsigned char crc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117997
Jakub Jelinek changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118387
--- Comment #8 from Jakub Jelinek ---
My reading of the patch review comment
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673245.html
was that this is a defect in the standard and we should treat it as a reason to
make the defaulted fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117997
--- Comment #11 from Jakub Jelinek ---
Reduced testcase (again -O2 -fpie misbehaves, -O2 or -O2 -fpie
-fno-optimize-crc is fine) below.
While it is still quite large, most of it actually isn't executed at all, what
misbehaves is the
baz function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117997
--- Comment #10 from Jakub Jelinek ---
Verified on current trunk.
Seems the crc pass matched:
crc_36 = .CRC (crc_16, 0, 7);
crc_93 = .CRC (crc_32, 0, 7);
crc_83 = .CRC (crc_52, 0, 32773);
and they are expanded using some table lookup or wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117997
Jakub Jelinek changed:
What|Removed |Added
Attachment #60090|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117997
Jakub Jelinek changed:
What|Removed |Added
Attachment #60089|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117997
--- Comment #7 from Jakub Jelinek ---
Created attachment 60093
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60093&action=edit
crc3.c
So far not really reduced testcase.
gcc -c -O2 -fPIE -o crc1.{o,i}; gcc -c -O2 -fPIE -o crc2.{o,i}; gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117997
--- Comment #6 from Jakub Jelinek ---
Created attachment 60090
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60090&action=edit
crc2.i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117997
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118376
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118277
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
at gcc dot gnu.org |jakub at gcc dot gnu.org
Last reconfirmed||2025-01-09
Ever confirmed|0 |1
--- Comment #4 from Jakub Jelinek ---
Reduced testcase:
template
constexpr int
foo (const T (&x)[N])
{
return N;
}
static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118390
--- Comment #3 from Jakub Jelinek ---
There is still
pr118390.ii: In function ‘int main()’:
pr118390.ii:13604:67: error: too many initializers for ‘char [4]’
13604 | static constexpr auto std_to_char_array = std::to_array({
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118390
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118387
--- Comment #5 from Jakub Jelinek ---
Note, for the second testcase, what happened is that when we synthetize the
defaulted operator <=>, we indeed construct that static cast as required in the
standard and figure out it is invalid, but we do so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118387
--- Comment #4 from Jakub Jelinek ---
Created attachment 60085
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60085&action=edit
gcc15-pr118387.patch
Untested fix for the ICE.
Or:
--- gcc/cp/method.cc.jj2025-01-08 23:11:23.375456869 +0100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118387
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
at gcc dot gnu.org |jakub at gcc dot gnu.org
Last reconfirmed||2025-01-09
Ever confirmed|0 |1
--- Comment #4 from Jakub Jelinek ---
Created attachment 60084
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60084&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118342
--- Comment #12 from Jakub Jelinek ---
(In reply to Uroš Bizjak from comment #11)
> (In reply to Jakub Jelinek from comment #10)
> > Guess the first question is if we want to change this for GCC 15 or if that
> > is too late for that.
>
> I thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118342
--- Comment #10 from Jakub Jelinek ---
Guess the first question is if we want to change this for GCC 15 or if that is
too late for that.
As you wrote, the DImode with SImode result pattern could be also using
if_then_else, and then for the zext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118342
--- Comment #8 from Jakub Jelinek ---
(In reply to Uroš Bizjak from comment #7)
> (In reply to Jakub Jelinek from comment #6)
> > Yes, so we can use it for a == 0 ? prec : __builtin_ctzll (a); but not say
> > (with small middle-end enhancements)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117960
Jakub Jelinek changed:
What|Removed |Added
Summary|[13/14 Regression] "Note|[13 Regression] "Note that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118024
--- Comment #8 from Jakub Jelinek ---
Fixed for 14.3 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117851
--- Comment #9 from Jakub Jelinek ---
Fixed for 14.3 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117614
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116799
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43374
--- Comment #14 from Jakub Jelinek ---
Fixed for 14.3 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117439
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13/14 Regression] ICE |[12/13 Regression] ICE in
1 - 100 of 14257 matches
Mail list logo
