https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114485
--- Comment #11 from Richard Biener ---
Created attachment 57871
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57871=edit
patch
I'm testing this (on x86_64-linux).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114537
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:1baec8deb014b8a7da58879a407a4c00cdeb5a09
commit r14-9784-g1baec8deb014b8a7da58879a407a4c00cdeb5a09
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114578
Bug ID: 114578
Summary: [13/14 Regression] memory hog, virtual memory
exhausted, building a c++ file on arm-linux-gnueabihf
Product: gcc
Version: 13.2.1
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29231
Iain Sandoe changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114555
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114579
--- Comment #1 from Richard Biener ---
Created attachment 57872
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57872=edit
patch
Doing this no longer will be able to handle A conflicts B, B conflicts C
but A does not conflict C. But it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114580
Bug ID: 114580
Summary: Bogus warning on if constexpr
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114569
Jens Maurer changed:
What|Removed |Added
CC||jens.maurer at gmx dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66766
Andrew Pinski changed:
What|Removed |Added
Summary|Reference to an “auto” |static class member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114485
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114485
--- Comment #10 from Richard Biener ---
/* Init_expr will be update by vect_update_ivs_after_vectorizer,
if niters or vf is unkown:
For shift, when shift mount >= precision, there would be UD.
For mult, don't known how to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99195
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Known to work||14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114579
Bug ID: 114579
Summary: RTL expansion add_scope_conflicts is slow
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773
Sainan changed:
What|Removed |Added
CC||sainan+gcc.bugzilla@calamit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114485
--- Comment #12 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:85621f98d245004a6c9787dde21e0acc17ab2c50
commit r14-9786-g85621f98d245004a6c9787dde21e0acc17ab2c50
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247
--- Comment #5 from Robin Dapp ---
This fixes the test case for me locally, thanks.
I can run the testsuite with it later if you'd like.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114580
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-04-04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247
--- Comment #4 from Martin Jambor ---
I don't seem to be able to get riscv64 qemu running in reasonable
time. Can someone please verify that the following patch fixes
the issue?
diff --git a/gcc/ipa-param-manipulation.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114454
--- Comment #4 from Andreas Schwab ---
<83> is the UTF-8 encoding of U00C3 and <84> is the UTF-8 encoding of
U0084.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114581
Bug ID: 114581
Summary: go.test/test/fixedbugs/issue22881.go FAILs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29231
--- Comment #8 from Iain Sandoe ---
A secondary comment - the wiring up of the built-ins that allocate/deallocate
trampoline entries makes the underlying mechanism opaque to the middle end
consumer.
So, although the current example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773
--- Comment #4 from Wilco ---
(In reply to Sainan from comment #3)
> I seem to be having a related issue, although in my case the struct looks
> like this:
>
> template
> struct Data
> {
> T* data;
> std::atomic_uint count;
> bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114485
Richard Biener changed:
What|Removed |Added
Summary|[13/14 Regression] Wrong|[13 Regression] Wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415
--- Comment #5 from Vladimir Makarov ---
After some considerations, I've decided to fix it in the scheduler.
Such approach solves the problem for all targets and schedulers, still
permitting live range shrinkage (important for space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #23 from Jan Hubicka ---
The patch looks reasonable. We probably could hash the padding vectors at
summary generation time to reduce WPA overhead, but that can be done
incrementally next stage1.
I however wonder if we really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114454
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Ian Lance Taylor ---
> I'm not sure what is going on here. The test as such does not require a UTF-8
> LANG. That is, I can run the compiler and the test with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52357
Rainer Orth changed:
What|Removed |Added
Status|SUSPENDED |NEW
--- Comment #7 from Rainer Orth ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773
--- Comment #5 from Sainan ---
(In reply to Wilco from comment #4)
> The atomic will also set correct struct alignment.
My thinking was that maybe this is not the case (= standard library issue)
since both GCC and Clang seem to be causing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |REOPENED
--- Comment #6
ing to compile source file which creates a std::variant which holds
std::string and push it to std::vector, I get bogus warning about string's
internals being left uninitialized. This only happens when using -O3, lower
optimisations do not exhibit this issue.
$ g++ --version
g++ (GCC) 14.0.1 20240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #31 from anlauf at gcc dot gnu.org ---
I've just checked the various comments.
What's left:
- comment#2 : the testcase still fails. See also comment#7 about the invalid
partial initialization
- lack of diagnostics of overlapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114593
Bug ID: 114593
Summary: Failed type conversion on non-tagged derived type
inside a generic unit
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
Jakub Jelinek changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112980
--- Comment #12 from Giuliano Belinassi
---
With your patch we have:
> .LPFE0:
> nop
> nop
> nop
> nop
> nop
> nop
> nop
> nop
> nop
> nop
> nop
> nop
> nop
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #12 from Jakub Jelinek ---
The user align:32 MEM_REF comes from
(gdb) p debug (dr_info->dr)
#(Data Ref:
# bb: 21
# stmt: a[j_38][k_41] = _48;
# ref: a[j_38][k_41];
# base_object: a;
# Access function 0: {0, +, 1}_3
# Access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-04-04
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103944
--- Comment #15 from GCC Commits ---
The releases/gcc-12 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:5a72912f9b0a5aa3c5a726ec499137c189921f9b
commit r12-10309-g5a72912f9b0a5aa3c5a726ec499137c189921f9b
Author: Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110624
--- Comment #10 from GCC Commits ---
The releases/gcc-12 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:a17f5a03e93d2cc6fd40cef6ab3930ba019f804a
commit r12-10310-ga17f5a03e93d2cc6fd40cef6ab3930ba019f804a
Author: Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114587
--- Comment #2 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:1df56719bd868c58466a549b25d7064dac3eb456
commit r14-9791-g1df56719bd868c58466a549b25d7064dac3eb456
Author: H.J. Lu
Date: Thu Apr 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.4
Summary|rtl-reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175
--- Comment #62 from GCC Commits ---
The releases/gcc-13 branch has been updated by Edwin Lu :
https://gcc.gnu.org/g:c4eff4ece764d836eb7ee0c0163780d100471730
commit r13-8579-gc4eff4ece764d836eb7ee0c0163780d100471730
Author: Edwin Lu
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773
--- Comment #6 from Wilco ---
(In reply to Sainan from comment #5)
> (In reply to Wilco from comment #4)
> > The atomic will also set correct struct alignment.
>
> My thinking was that maybe this is not the case (= standard library issue)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773
--- Comment #8 from Wilco ---
(In reply to Sainan from comment #7)
> (In reply to Wilco from comment #6)
> > That does not make any sense. The only thing I think might happen is that
> > your structure is not correctly aligned (for example by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773
--- Comment #9 from Sainan ---
(In reply to Wilco from comment #8)
> So it's unaligned then, and that's not supported. And you're lucky your
> specific alignment happens to work on v8.4 cores - it would fail for other
> offsets.
I'd say
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114590
Bug ID: 114590
Summary: [14 Regression] FAIL:
gcc.target/i386/apx-ndd-ti-shift.c (test for excess
errors)
Product: gcc
Version: 14.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114590
H.J. Lu changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #10 from Jakub Jelinek ---
Note, the a array which is the object into which the misaligned store happens
has
align:128 so assuming 256-bit alignment into it seems wrong:
(insn 57 56 58 4 (set (reg:V8SF 135 [ vect__33.37 ])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #15 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #14)
> Marking for 14 as well because I believe the trunk commit just made it
> latent there rather than fixed.
You might be able to reproduce it on the trunk with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114588
--- Comment #1 from Andrew Pinski ---
Confirmed. I should note that Red/Green is the opposite meaning in some places
than western cultures. That is Red is good and Green is bad. Most of China is
where that is true.
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480
--- Comment #20 from Alexander Monakov ---
(note that if you uninclude the testcase and compile with -fno-exceptions it's
much faster)
On the smaller testcase from comment 14, prune_unused_phi_nodes invokes
gcc_qsort 53386 times. There are two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568
--- Comment #20 from GCC Commits ---
The releases/gcc-12 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:753d7e4edf63c4ff690858da11bf0d59aa24e1bb
commit r12-10311-g753d7e4edf63c4ff690858da11bf0d59aa24e1bb
Author: Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114415
--- Comment #6 from GCC Commits ---
The master branch has been updated by Vladimir Makarov :
https://gcc.gnu.org/g:a24476422ba311b83737cf8bdc5892a7fc7514eb
commit r14-9793-ga24476422ba311b83737cf8bdc5892a7fc7514eb
Author: Vladimir N. Makarov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114587
--- Comment #1 from H.J. Lu ---
We should define a macro for each APX command-line option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
--- Comment #14 from Nicolas Boulenguez ---
The new version does not change much, but I am only posting it in order to
prevent duplicated work.
I will try to split the timespec changes and the timeval+Sockets changes, then
attempt a build.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114572
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=114588
Bug ID: 114588
Summary: Analyzer buffer overflow ASCII art hardcodes "RED" and
"GREEN" as the terminal colors
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
Summary|Misaligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566
--- Comment #11 from Jakub Jelinek ---
Seems like vectorizer bug to me. The _42 + 128 store is to
MEM [(float *)_42 + 128B];
aka:
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114589
Bug ID: 114589
Summary: missed optimization: losing bool range information
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114589
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114589
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> Confirmed.
>
> Why didn't sink1 push _10, _13, _12, and _11 past the conditional here ...
> If it did that I think it might have optimized correctly.
Because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45431
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049
--- Comment #11 from GCC Commits ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:b03827b261d3c8351f9c208fe2d89ca987a25bee
commit r13-8584-gb03827b261d3c8351f9c208fe2d89ca987a25bee
Author: Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
--- Comment #6 from GCC Commits ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:02a1d49da8f95a128d131747546921b67818d144
commit r13-8586-g02a1d49da8f95a128d131747546921b67818d144
Author: Iain Sandoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100611
vipcxj at 126 dot com changed:
What|Removed |Added
CC||vipcxj at 126 dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100611
--- Comment #8 from Avi Kivity ---
Congratulations on getting the account!
The bug is fixed though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100611
--- Comment #9 from Avi Kivity ---
At least, on 13.2.1. Maybe a backport is required.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104585
Bill Long changed:
What|Removed |Added
CC||longb at cray dot com
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773
--- Comment #7 from Sainan ---
(In reply to Wilco from comment #6)
> That does not make any sense. The only thing I think might happen is that
> your structure is not correctly aligned (for example by using a custom
> memory allocator). Can you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104585
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=114566
--- Comment #13 from Jakub Jelinek ---
Ah, vect_analyze_data_refs_alignment -> vect_compute_data_ref_alignment
actually checks for this case
1136 if (max_alignment < vect_align_c
1137 || !vect_can_force_dr_alignment_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
Bug ID: 114591
Summary: rtl-reload introduce an extra load operation since
gcc-12
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114590
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78219
--- Comment #12 from Bill Long ---
Has this been fixed in a more recent version of gfortran?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Known to work||12.3.0, 13.2.1, 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114577
--- Comment #1 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:86dce005a1d440154dbf585dde5a2dd4cfac7a05
commit r14-9787-g86dce005a1d440154dbf585dde5a2dd4cfac7a05
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247
--- Comment #6 from Robin Dapp ---
Testsuite looks unchanged on rv64gcv.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114582
Bug ID: 114582
Summary: go.test/test/fixedbugs/issue34123.go FAILs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #77 from Ilya Leoshkevich ---
Apparently fixing the message in GCC will produce maintenance overhead [1]. If
that's not very important to you, I'd rather leave this message as is.
[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114577
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574
--- Comment #15 from Martin Uecker ---
Created attachment 57874
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57874=edit
patch
Tentative patch for the fix that makes the incomplete types have structural
equivalence at the beginning and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114583
Bug ID: 114583
Summary: go.test/test/fixedbugs/issue4562.go FAILs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114584
Bug ID: 114584
Summary: go.test/test/nil.go FAILs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114585
Bug ID: 114585
Summary: Incorrect boolean value with O2/O3 optimisation
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114585
Andreas Schwab changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114586
Bug ID: 114586
Summary: Contradictory paths in reasoning for memory leak
diagnostic
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
Nicolas Boulenguez changed:
What|Removed |Added
Attachment #57865|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114585
--- Comment #2 from Jonathan Wakely ---
The bug reporting guidelines you were asked to read say to try
-fsanitize=undefined and if you'd done that you'd have seen errors:
https://godbolt.org/z/bscj8q9rr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114587
Bug ID: 114587
Summary: -mapxf should define a macro
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114587
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |14.0
Ever confirmed|0
101 - 192 of 192 matches
Mail list logo
