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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118534
Bug ID: 118534
Summary: [15 Regression] constant evaluation failure with
RAW_DATA_CST
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118532
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2025-01-17
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118528
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118532
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118532
Bug ID: 118532
Summary: [15 Regression] add_list_candidates not handling
RAW_DATA_CST right
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118528
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2025-01-17
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118528
Bug ID: 118528
Summary: [15 Regression] Template argument deduction failure
with RAW_DATA_CST
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
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 #1
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 #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118519
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118516
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
CC|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118513
Bug ID: 118513
Summary: ICE with modules and structured binding using
std::tuple*
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118511
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118511
Jakub Jelinek changed:
What|Removed |Added
Target||s390x-linux
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118511
Bug ID: 118511
Summary: [15 Regression] ICE when compiling s390-tools since
r15-2002
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
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|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118497
Bug ID: 118497
Summary: [15 Regression] Worse code generated on i686-linux
since r15-1619
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
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 #2
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118400
Jakub Jelinek changed:
What|Removed |Added
Summary|[14/15 Regression] memory |[14/15 Regression] memory
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 #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118470
Jakub Jelinek changed:
What|Removed |Added
CC||iains at gcc dot gnu.org,
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 #2
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 #9
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|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118456
Bug ID: 118456
Summary: [15 Regression] wrong code due to ifcombine since
r15-6773
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118408
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
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 #7
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118415
Bug ID: 118415
Summary: [15 Regression] crc optimization uses user accessible
symbols
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
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 #5
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|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118390
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
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 #1
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118376
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
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 5303 matches
Mail list logo
