https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103027
--- Comment #5 from Eric Gallager ---
Example bug that this warning flag could have found, if the string involved
were a C string: https://twitter.com/nyt_first_said/status/1513148451210637313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105260
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104010
--- Comment #12 from Christophe Lyon ---
The test in arm/simd/neon-vcmp.c currently fails, and passes with your
candidate patch, thanks.
(I wrote that test before the regression, and noticed it had regressed while
working on my MVE/VCMP patche
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105183
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105183
--- Comment #6 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:dd61ee6fde5fcf1d503b679bb9b5e0a0ba7a515d
commit r12-8139-gdd61ee6fde5fcf1d503b679bb9b5e0a0ba7a515d
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97296
Marek Polacek changed:
What|Removed |Added
Summary|[10/11/12 Regression] g++ |[10/11 Regression] g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #24 from Segher Boessenkool ---
Wrt keeping REG_EQUAL notes... If you want to keep them you need to make sure
they still are valid. GCC keeps those on i3, it is much too hard in general to
validate other such notes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105254
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105263
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=105263
--- Comment #2 from Richard Biener ---
Confirmed.
5336 /* Recurse on the LHS of the binary operator, which is guaranteed to
5337 be the non-leaf side. */
5338 tree new_rhs1
5339= rewrite_expr_tree (SSA_NAME_DEF_STMT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105263
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2022-04-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97296
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:85ae54e18b9a3cbe4feda921ecd77cf275177edf
commit r12-8138-g85ae54e18b9a3cbe4feda921ecd77cf275177edf
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #23 from Segher Boessenkool ---
i3 is not always the sole instruction that results from the combine: if a
single insn does not work, two are tried, and one of them is placed at i2.
It's something to consider, it has to be checked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105253
--- Comment #13 from Richard Biener ---
(In reply to Jakub Jelinek from comment #10)
> Created attachment 52796 [details]
> gcc12-pr105253.patch
>
> Now in (untested) patch form.
> Note, the kernel still should provide __popcount[sd]i2, but in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105260
--- Comment #6 from m.cencora at gmail dot com ---
Furthermore in all the scenarios the same function is called, with same
arguments, so the calling convention/ABI is same.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105253
--- Comment #12 from Richard Biener ---
(In reply to Jakub Jelinek from comment #9)
> Ah, I see, expression_expensive_p is called, but
> number_of_iterations_popcount when creating a CALL_EXPR only cares about
> TYPE_PRECISION and happily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105260
--- Comment #5 from m.cencora at gmail dot com ---
I've slighlty refactored the code, to remove the auto variables. This issue
remains
#include
inline unsigned deserializeUInt(const unsigned char* )
{
unsigned out;
__builtin_memcpy(,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105263
Bug ID: 105263
Summary: [9/10/11/12 Regression] ICE: gimple check: expected
gimple_assign(error_mark), have gimple_nop() in
gimple_assign_rhs1, at gimple.h:2655 with _Decimal64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105260
--- Comment #4 from m.cencora at gmail dot com ---
I dont think ABI is an issue here. The Foo variable is spilled into stack, and
then reloaded back into RDI register before invoking dummyFunc.
Also clang generates optimal code as can be seen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105260
--- Comment #3 from Richard Biener ---
That said, 'auto& arg' might just hide the interesting bit but my C++ fu is too
weak to see how un.value would differ.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105260
Richard Biener changed:
What|Removed |Added
Keywords||ABI, wrong-code
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105258
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105258
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105260
--- Comment #1 from Richard Biener ---
Well, it simply looks like the calling conventions for dummyFunc are different
with the ABI in effect depending on the PODness(?), and the code is as
optimized as it can be.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104010
--- Comment #11 from Richard Biener ---
The testcases from PR103941 are also fixed - I fear this might cause quite some
extra BB vectorization, so not sure if it is good to do right now. OTOH it's
probably the last chance to get benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105262
Bug ID: 105262
Summary: Consider adding
std::__new_allocator::allocate(size_type, nothrow_t)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104010
--- Comment #10 from Richard Biener ---
(In reply to Richard Earnshaw from comment #7)
> Options to reproduce on arm-none-eabi:
>
> -O3 -mcpu=cortex-a9 -mfpu=neon-fp16 -mfloat-abi=hard -o - vect.c -S
> -fdump-tree-all-details
Can you create a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104010
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104010
--- Comment #8 from Richard Biener ---
This is likely because of a similar issue as PR103941 and related to pattern
recognition. We're trying to be more precise now but with patterns there are
still issues and we are now erroring on the "safe"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105258
--- Comment #1 from Jonathan Wakely ---
The simplest solution would be to just use std::allocator which already does
the right thing, but that would break if there is a program-defined
specialization of std::allocator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105258
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
Jonathan Wakely changed:
What|Removed |Added
Status|SUSPENDED |NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105261
Bug ID: 105261
Summary: schedule-insns2 and ipa-sra make alive constant
variables not available
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105242
--- Comment #2 from Jakub Jelinek ---
Why do you say accepts invalid for C/C++?
void
foo (int i1, int i2, int j1, int j2, int k1, int k2)
{
int k = 1;
#pragma omp target parallel for simd collapse(3) firstprivate (k)
for (int ii = i1; ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81122
Dvir Yitzchaki changed:
What|Removed |Added
CC||dvirtz at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105247
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105247
--- Comment #3 from Jakub Jelinek ---
The problem is that the ia64 backend for some strange reason uses DImode for
the
shift last operands, while e.g. in GIMPLE they are converted to
integer_type_node or so:
/* Why oh why didn't Intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93602
--- Comment #17 from Jonathan Wakely ---
I confirmed that --without-libiconv-prefix doesn't work. With GNU libiconv
installed as /usr/local/lib/libiconv.so.2 it breaks the compiler:
/gccobj/./gcc/xgcc -B/gccobj/./gcc/ -dumpspecs > tmp-specs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104010
--- Comment #7 from Richard Earnshaw ---
Options to reproduce on arm-none-eabi:
-O3 -mcpu=cortex-a9 -mfpu=neon-fp16 -mfloat-abi=hard -o - vect.c -S
-fdump-tree-all-details
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104010
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105253
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |12.0
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105253
--- Comment #11 from Jakub Jelinek ---
This is a regression (as in we don't want such a call in that case for
performance reasons and in the past we didn't emit it).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105253
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105260
Bug ID: 105260
Summary: Union with user-defined empty destructor leads to
worse code-gen
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105253
--- Comment #9 from Jakub Jelinek ---
Ah, I see, expression_expensive_p is called, but number_of_iterations_popcount
when creating a CALL_EXPR only cares about TYPE_PRECISION and happily creates
__builtin_popcountl with unsigned long long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105253
--- Comment #8 from Jakub Jelinek ---
Reduced to just -O2:
int
foo (unsigned long long *p)
{
int i, cnt = 0;
unsigned long long elem;
for (i = 0; i < (256 / 64); i++)
{
elem = p[i];
for (; elem; cnt++)
elem &= elem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105253
--- Comment #7 from Richard Biener ---
(In reply to Jakub Jelinek from comment #6)
> Note, there is some code to not do this if we'd not expand the builtin inline
> since r9-4030-g06a6b46a16f9287a98aa , so I wonder what changed.
That only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105253
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105254
--- Comment #2 from Arseny Solokha ---
I tried to replace -mcpu w/ individual options reported by -Q --help=target and
failed. But yes, -mcpu=zeus also works and reveals that it is likely [12
Regression].
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105259
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:9645279722233bb779cc6eca02687a732d4834e5
commit r12-8137-g9645279722233bb779cc6eca02687a732d4834e5
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105255
--- Comment #1 from Giovanni Cerretani ---
I attach also a more comprehensive test that also checks conversions from
integer to enumeration types (https://godbolt.org/z/jbe76E3c1). The behavior of
direct-list-initialization has changed on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105259
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105259
Bug ID: 105259
Summary: gcc.target/i386/auto-init-4.c FAILs
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105258
Bug ID: 105258
Summary: std::get_temporary_buffer() does not respect alignment
(affects std::stable_sort())
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105246
--- Comment #2 from Andrew Stubbs ---
When we first coded this we only had the GCN3 ISA manual, which says nothing
about the accuracy.
Now I look in the Vega manual (GCN5) I see:
Square root with perhaps not the accuracy you were hoping for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105257
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105257
Bug ID: 105257
Summary: [8/9/10/11/12 regression] ICE in final_scan_insn_1, at
final.cc:2811
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103069
--- Comment #21 from CVS Commits ---
The master branch has been updated by Hongyu Wang :
https://gcc.gnu.org/g:522f25e90c781d284f8347a04940db8b41c42fd5
commit r12-8136-g522f25e90c781d284f8347a04940db8b41c42fd5
Author: Hongyu Wang
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234
--- Comment #14 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:41f8f8b8a4ffcf28961cdc077fd7f0770f4bb7cc
commit r12-8135-g41f8f8b8a4ffcf28961cdc077fd7f0770f4bb7cc
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105238
--- Comment #3 from Martin Liška ---
> I am happy to test the patch, but not quite sure how to proceed.
I would recommend building the current master (or you can wait for a couple of
weeks and apply it on the top of GCC 12.1 release that will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105254
--- Comment #1 from Martin Liška ---
Bisection would be difficult as it's closely related to -mcpu=demeter. Is there
any other CPU that triggers that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-04-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104912
--- Comment #9 from Richard Biener ---
(In reply to CVS Commits from comment #8)
> The master branch has been updated by Richard Biener :
>
> https://gcc.gnu.org/g:ac8340ee4d1e65f3fd41c547b16895875f4aefa7
>
> commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105256
Bug ID: 105256
Summary: ICE compiling firefox-99
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105254
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105140
Bug 105140 depends on bug 105250, which changed state.
Bug 105250 Summary: ICE: in fold_convert_loc, at fold-const.cc:2581 with
conflicting function redeclaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105250
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105250
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105250
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:4e892de6774f86540d36385701aa7b0a2bba5155
commit r12-8134-g4e892de6774f86540d36385701aa7b0a2bba5155
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104912
--- Comment #8 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:ac8340ee4d1e65f3fd41c547b16895875f4aefa7
commit r12-8132-gac8340ee4d1e65f3fd41c547b16895875f4aefa7
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105252
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308
Kamil Dudka changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #22 from rguenther at suse dot de ---
On Wed, 13 Apr 2022, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
>
> --- Comment #21 from Eric Botcazou ---
> > I'm not sure that's a general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #21 from Eric Botcazou ---
> I'm not sure that's a general enough fix though since we seem to drop
> the REG_EQUAL note and as soon as we do that there's a disconnect
> between what CFG generation thinks throws and what combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105255
Bug ID: 105255
Summary: Narrowing conversion from enumerator to integer not
detected
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146
Richard Biener changed:
What|Removed |Added
Target Milestone|11.3|11.4
Priority|P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102301
--- Comment #9 from Jonathan Wakely ---
https://cplusplus.github.io/LWG/issue3690
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105253
--- Comment #5 from Richard Biener ---
We're not checking for an optab here (that's on purpose IIRC). The code using
the niter analysis result is responsible to do cost checking. The builtin
is recognized via number_of_iterations_popcount.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105252
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105250
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=105242
Tobias Burnus changed:
What|Removed |Added
Keywords|ice-on-valid-code |accepts-invalid, diagnostic
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105253
--- Comment #4 from Andrew Pinski ---
With 12.0.1 20220213, I didn't get any popcountdi2 calls.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105247
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105246
--- Comment #1 from Richard Biener ---
can one improve the precision by employing some additional NR step or so, using
v_sqrt only for the initial guess? I agree that just v_sqrt isn't good for
-funsafe-math-optimizations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105254
Bug ID: 105254
Summary: ICE in exact_div, at poly-int.h:2219
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103871
Richard Biener changed:
What|Removed |Added
Target Milestone|11.3|11.4
Priority|P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105186
Jakub Jelinek changed:
What|Removed |Added
Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in
101 - 188 of 188 matches
Mail list logo
