zstd
gcc version 13.0.0 20220729 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429
--- Comment #10 from Andrew Pinski ---
It should be noted almost nobody does "make clean" really. Most just remove the
build directory instead.
Is there a reason why you build scripts are doing "make clean"?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429
Andrew Pinski changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106079
--- Comment #4 from seurer at gcc dot gnu.org ---
The patch causes a bunch of new failures:
FAIL: gfortran.dg/c-interop/allocatable-dummy.f90 -Os execution test
FAIL: gfortran.dg/c-interop/allocate-errors.f90 -O0 execution test
FAIL: gfort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429
--- Comment #8 from Martin Vahi ---
Thank You for the answers/replies.
As of 2022_07_30 I am not familiar with the GCC source code, nor do I know the
GCC build system, but as someone, who can do configure-make-make_install, I
have the following
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429
--- Comment #7 from Andrew Pinski ---
(In reply to Martin Vahi from comment #5)
> Created attachment 53385 [details]
This is a failure while "make clean".
And your patch does not even touch anything related to libgcc and "make clean".
So this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429
--- Comment #6 from Martin Vahi ---
Created attachment 53386
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53386&action=edit
List of changes that allow temporary use of an alternative Bash binary.
Too old Bash version:
GNU bash, ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106429
--- Comment #5 from Martin Vahi ---
Created attachment 53385
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53385&action=edit
Console Output of the Bash Version Related GCC Build Failure
...
gmake[1]: Entering directory
'/opt/andm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106147
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106079
--- Comment #3 from seurer at gcc dot gnu.org ---
I tried the patch on trunk and it fixed the failure. I am trying a full make
check there and with gcc 12.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980
--- Comment #6 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #5)
> So, shall we temporarily disable -mforce-indirect-call during the mi thunk
> output?
Something like this
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980
--- Comment #5 from Jakub Jelinek ---
So, shall we temporarily disable -mforce-indirect-call during the mi thunk
output?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980
--- Comment #4 from H.J. Lu ---
We don't have available scratch registers in 32-bit mode for
x86_output_mi_thunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106469
--- Comment #7 from Andrew Pinski ---
"An unsigned overflow" does not exist.
That is the point here.
And that is why this sanitizer is bogus and should never be used.
And yes overflow wrapping is sometimes a bug in the code but if the code
depe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
John David Anglin changed:
What|Removed |Added
Build|powerpc64-linux-gnu,|powerpc64-linux-gnu,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106480
Bug ID: 106480
Summary: FAIL: gcc.dg/Warray-bounds-48.c pr102706 (test for
warnings, line 33)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106469
--- Comment #6 from Henry ---
> This sanitizer is stupid.
That is an unjust comment on great work from the LLVM team. An unsigned
overflow in user code is almost always a bug due to some oversight, there is no
denying that. Look at Arianne 5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106479
Bug ID: 106479
Summary: FAIL: gcc.dg/analyzer/pr104308.c (test for warnings,
line 9)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106478
Bug ID: 106478
Summary: GCC rejects valid code involving partial
specialization of variable template
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-07-29
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106474
--- Comment #2 from Andrew Macleod ---
(In reply to Richard Biener from comment #1)
> For the failing case we see
>
>:
> if (c_5(D) == s_6(D))
> goto ; [INV]
> else
> goto ; [INV]
>
>:
> if (c_5(D) != 0)
> goto ; [INV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68210
Matthijs Kooijman changed:
What|Removed |Added
CC||matthijs at stdin dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477
--- Comment #3 from Matthijs Kooijman ---
Created attachment 53384
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53384&action=edit
Testcase - linker script for ATSAMD21G18 (Arduino zero)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477
--- Comment #2 from Matthijs Kooijman ---
Created attachment 53383
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53383&action=edit
Testcase - startup code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477
--- Comment #1 from Matthijs Kooijman ---
Created attachment 53382
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53382&action=edit
Testcase - main code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106477
Bug ID: 106477
Summary: With -fno-exception operator new(nothrow) aborts
instead of returning null
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99410
--- Comment #9 from Giulio Benetti ---
This bug shows up with gcc 11.3.0 and 12.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106315
--- Comment #5 from H.J. Lu ---
Here is the testcase:
---
void
bar(int *indices, int max_iter, int *actual_indices,
int *iters_per_dim, int N_dims)
{
int iter = 0;
int sum_indices = 0;
int flag, k;
while (iter < max_iter) {
for (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458
--- Comment #6 from dave.anglin at bell dot net ---
On 2022-07-29 8:50 a.m., dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458
>
> --- Comment #5 from dave.anglin at bell dot net ---
> On 2022-07-28 4:12 a.m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106079
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106475
Christoph Müllner changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 106475, which changed state.
Bug 106475 Summary: Loop vectorizer prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106475
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105980
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106475
--- Comment #2 from Christoph Müllner ---
Yes, you are right!
I haven't noticed that the longer sequence requires only half of the loop
iterations when compared to the shorter sequence.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106007
Tim Lange changed:
What|Removed |Added
CC||tlange at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617
--- Comment #15 from Michael_S ---
(In reply to Richard Biener from comment #14)
> (In reply to Michael_S from comment #12)
> > On related note...
> > One of the historical good features of gcc relatively to other popular
> > compilers was absen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106466
--- Comment #6 from tt_1 ---
works with:
gcc-10.3.0
gcc-10.3.1_p20211126
gcc-11.3.0
does not work with:
gcc-10.4.0
the segfault is sort of spurious, its an about 1/5 to 1/7 chance for me. Is
that something you can work with?
and indeed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106476
Bug ID: 106476
Summary: ICE generating FOLD_EXTRACT_LAST
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: tree-optimiza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458
--- Comment #5 from dave.anglin at bell dot net ---
On 2022-07-28 4:12 a.m., rguenth at gcc dot gnu.org wrote:
> Can you check trunk / the gcc 12 branch head?
Test fails in the same way with trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102446
--- Comment #17 from Jakub Jelinek ---
So dup or related to PR106032.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102446
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
--- Comment #16 from Jakub Jelinek --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106475
--- Comment #1 from Richard Biener ---
The loop seems to be vectorized just fine? The issue is just that we need a
runtime alias check because of the variable stride and the fact that we need a
VF of two to fill up to 16 byte vectors:
.L5:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68485
--- Comment #11 from Giulio Benetti ---
And it shows up on gcc 12.1.0 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101839
--- Comment #7 from Richard Biener ---
Honza?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102446
Richard Biener changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11 Regression] wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106073
Richard Biener changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68485
Giulio Benetti changed:
What|Removed |Added
CC||giulio.benetti@benettiengin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106475
Bug ID: 106475
Summary: Loop vectorizer prevents vectorization
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #18 from Richard Biener ---
(In reply to Richard Biener from comment #17)
> Seeing
>
> Trying 21 -> 24:
>21: r150:V4SI=vec_select(vec_concat(r146:V4SI,r141:V4SI),parallel)
> REG_DEAD r146:V4SI
> REG_DEAD r141:V4SI
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #17 from Richard Biener ---
Seeing
Trying 21 -> 24:
21: r150:V4SI=vec_select(vec_concat(r146:V4SI,r141:V4SI),parallel)
REG_DEAD r146:V4SI
REG_DEAD r141:V4SI
24: {r151:SI=vec_select(r150:V4SI,parallel);clobber scrat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106467
--- Comment #4 from Tobias Burnus ---
For completeness, the testcase
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/599041.html
was committed as
https://gcc.gnu.org/r13-1893-g85fe7e7dd1f1461b86d92a3a0c1bfd97a06efcc0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679
Richard Biener changed:
What|Removed |Added
Known to work||13.0
Summary|[12/13 Regress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:49ba4fdeb648c149fa7d964ba812084262c3d06f
commit r13-1891-g49ba4fdeb648c149fa7d964ba812084262c3d06f
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106474
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78081
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2018-09-16 00:00:00 |2022-7-29
--- Comment #6 from Richard B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104443
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|SUSPENDED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104443
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:b5f5d1b36edbcd7d923f2e2653e54e52637c715b
commit r13-1890-gb5f5d1b36edbcd7d923f2e2653e54e52637c715b
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106422
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106422
--- Comment #15 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:4894ba078692a780a461d2f358b5dfaa25719859
commit r13-1889-g4894ba078692a780a461d2f358b5dfaa25719859
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106399
--- Comment #6 from Eric Botcazou ---
Created attachment 53380
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53380&action=edit
Incomplete fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106399
--- Comment #5 from Eric Botcazou ---
This is an equivalent Ada testcase:
function Foo (A: Integer) return Integer is
function A2 return Integer is (A * A);
begin
return A2;
end;
with the same issue. We have been using the to-be-attache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106474
Bug ID: 106474
Summary: DCE depends on how if expressions are nested
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106449
--- Comment #11 from Jakub Jelinek ---
Fixed on the trunk so far. Will backport later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106464
Bug 106464 depends on bug 106448, which changed state.
Bug 106448 Summary: [OpenMP] atomic compare – g++ wrongly accepts parenthesized
condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106448
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106448
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
--- Comment #4 from Petr Sumbera ---
(In reply to Richard Biener from comment #3)
> There is dependencies = { module=all-target-libgo;
> on=all-target-libbacktrace; }
> in Makefile.def so there's sth fishy going on. Do you use GNU make?
Yes. G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
Richard Biener changed:
What|Removed |Added
Target||x86_64-pc-solaris2.11
Ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106448
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2dcceedb3c121f2498ae58d8414e7b8454b7bf55
commit r13-1888-g2dcceedb3c121f2498ae58d8414e7b8454b7bf55
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106471
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106449
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:97d32048c04e9787fccadc4bae1c042754503e34
commit r13-1887-g97d32048c04e9787fccadc4bae1c042754503e34
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106342
--- Comment #7 from Jakub Jelinek ---
Maybe.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106466
--- Comment #5 from Richard Biener ---
can't reproduce with a cross from x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106465
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-07-29
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106473
Bug ID: 106473
Summary: -Wanalyzer-malloc-leak false positive regression when
returning heap-allocation through nested pointers
Product: gcc
Version: 12.0
Status: UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106470
--- Comment #8 from Alexander Monakov ---
But that's the point of many warnings, isn't it? To help the user understand
what's wrong when the code is bad? And bogus warnings just confuse more.
76 matches
Mail list logo
