https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94780
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.5
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94784
Bug ID: 94784
Summary: ICE: in simplify_vector_constructor, at
tree-ssa-forwprop.c:2482
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94782
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94784
--- Comment #1 from Fei Yang ---
I did some check and it looks like everything works fine before the ICE.
The reason for the assert is that applying VIEW_CONVERT_EXPR to two general
vectors is dangerous in this context. If through some bug we e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94783
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |middle-end
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94784
--- Comment #2 from Fei Yang ---
Will propose a patch for review.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9612a4833d761e3beda083a3e4dc92feba3b01bc
commit r10-7985-g9612a4833d761e3beda083a3e4dc92feba3b01bc
Author: Jakub Jelinek
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94781
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94771
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
--- Comment #6 from Bence Szabó ---
> Ah, then it is not c++14 vs. c++17 ABI incompatibility, but some bug in
> va_arg passing of such classes for mingw.
It seems so. In t032 I got rid of the crashing tests (30, 56, 77, 80, 89, 100,
117, 134, 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94785
Bug ID: 94785
Summary: Failure to detect abs pattern using multiplication
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94711
--- Comment #1 from Jakub Jelinek ---
So, what exactly needs changing on ARM?
>From quick skimming, maybe arm_return_in_memory, very likely
aapcs_vfp_sub_candidate, and maybe arm_needs_doubleword_align.
What about comp_not_to_clear_mask_str_un ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94785
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |middle-end
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94786
Bug ID: 94786
Summary: Missed min/max pattern using xor+and+less
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94515
--- Comment #2 from CVS Commits ---
The master branch has been updated by Szabolcs Nagy :
https://gcc.gnu.org/g:acdf733634745548c0167c40bad80e6140ac2eeb
commit r10-7986-gacdf733634745548c0167c40bad80e6140ac2eeb
Author: Szabolcs Nagy
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52597
--- Comment #7 from Jonathan Wakely ---
Fixed by r197131
re PR c++/52597 ([C++11] confusing diagnostics for invalid use of
non-static member function in decltype)
PR c++/52597
* typeck.c (invalid_nonstatic_memfn_p): Use get_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94771
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from Jonathan Wakel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94787
Bug ID: 94787
Summary: Failure to detect single bit popcount pattern
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94767
--- Comment #3 from Jonathan Wakely ---
(In reply to jh718.park from comment #0)
> For these variables below,
>
> unsigned m_schemeEnd : 26;
> unsigned m_userStart;
>
> m_userStart == m_schemeEnd + 1
>
> this comparison emits a compiler warnin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
Bug ID: 94788
Summary: Severe regression leading to double free in tcache
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #1 from Jürgen Reuter ---
The change must have happened between Sunday, April 16 and Monday, April 27.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94739
Manfred Schwarb changed:
What|Removed |Added
CC||manfred99 at gmx dot ch
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94787
--- Comment #1 from Gabriel Ravier ---
Inversely, I'd also suggest doing the opposite. That is, if there is no
hardware popcount instruction, `__builtin_popcount(v) == 1` should be optimized
to `v && !(v & (v - 1))`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94771
Jonathan Wakely changed:
What|Removed |Added
CC|iains at gcc dot gnu.org |jason at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94789
Bug ID: 94789
Summary: Failure to take advantage of shift operand semantics
to turn subtraction into negate
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #28 from Richard Biener ---
OK, so more "advanced" testcases are a bit difficult because the
ref_always_accessed_p logic is too simple and it's required for
store-motion of accesses in conditional paths. Basically if
we have if (test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94780
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94790
Bug ID: 94790
Summary: Failure to use andn in specific pattern in which it is
available
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359
--- Comment #29 from Richard Biener ---
And another testcase showing that with a conditional invariant store we may
_never_ apply store-motion since conditional means we do not know the
original order of stores in the loop. *sigh*
typedef int A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94791
Bug ID: 94791
Summary: aarch64: -pg profiling is broken with pac-ret
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578
--- Comment #11 from Jan-Willem Blokland ---
If you make use of an temporary variable, it sounds like you will do an
additional memory copy. Therefore, I am wondering what the performance impact
will be. Naively, I would think the span solution w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #2 from Jürgen Reuter ---
This is our unit test, we now confirmed that this is the only problem, so the
only failing test: it really looks like that the finalizer for the subroutine
crashes, all routines inside the subroutine get exec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94792
Bug ID: 94792
Summary: Missed SLP optimization in pr65930-2.c variation
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
--- Comment #7 from Jakub Jelinek ---
So, does:
struct empty_base {};
struct S : public empty_base { struct{}a[1]; };
S s, a[5];
__attribute__((noipa)) void
foo (int x, ...)
{
__builtin_va_list ap;
__builtin_va_start (ap, x);
if (x != 1 &&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94749
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94793
Bug ID: 94793
Summary: Failure to optimize clz idiom
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94752
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94767
jh718.park at samsung dot com changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resoluti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94784
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:5328710be314dee43da8027dbff547d48b85e35e
commit r10-7987-g5328710be314dee43da8027dbff547d48b85e35e
Author: Fei Yang
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94781
--- Comment #5 from ishikawa,chiaki ---
Thank you for your comment.
(In reply to Richard Biener from comment #4)
> The time-report you attached is mostly flat and I don't see anything
> eye-popping pointing at a regression. With -O0 my GCC9 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94793
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94792
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94794
Bug ID: 94794
Summary: coroutines: Support is needed for symmetric transter
on targets without arbitrary indirect tail-calls
Product: gcc
Version: 10.0
Status: UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94790
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-04-27
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94789
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-04-27
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94794
Iain Sandoe changed:
What|Removed |Added
Target Milestone|--- |11.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94787
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-04-27
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Summary|Severe re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94786
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-04-27
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94789
--- Comment #2 from Andrew Pinski ---
Maybe (-b)&31 instead? And then the &31 could optimized out later on?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #4 from Jürgen Reuter ---
It is definitely this routine in our code that triggers this double free error:
call simulation%init ([procname1], .true., .true., global, alt_env=alt_env)
It really looks like that the garbage collector is m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
--- Comment #9 from Jonathan Wakely ---
At least, when using:
gcc version 9.2.1 20190827 (Fedora MinGW 9.2.1-1.fc31) (GCC)
and executing with Wine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
--- Comment #8 from Jonathan Wakely ---
The third __builtin_abort() is called:
if (__builtin_va_arg (ap, long long) != 2LL)
__builtin_abort ();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94748
--- Comment #1 from Richard Earnshaw ---
A BTI that's not immediately after a label looks wrong. Either it should be
removed entirely, or it should be merged with the preceding BTI.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94763
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
--- Comment #10 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #9)
> At least, when using:
> gcc version 9.2.1 20190827 (Fedora MinGW 9.2.1-1.fc31) (GCC)
> and executing with Wine.
Yeah, I can clearly see it in the assembly th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94795
Bug ID: 94795
Summary: Failure to use fast sbb method on x86 for spreading
any set bit to all bits
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
Jakub Jelinek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
--- Comment #12 from Jakub Jelinek ---
Another interesting test is:
struct S {};
void foo (int, int, int, int, int, int, int, int, int, S, S, S, S, int);
void baz (int, int, int, int, int, int, int, int, int, int);
int
bar ()
{
foo (1, 2, 3, 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #1 from Christophe Lyon ---
clang has implemented a warning for this case:
https://reviews.llvm.org/D28820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94789
--- Comment #3 from Gabriel Ravier ---
>From what I've seen, this optimisation could be useful on at least these
targets :
- x86_64
- i686
- aarch64
On other architectures I've looked at, either the optimization can't be done
and/or it's useles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #5 from Jürgen Reuter ---
(In reply to Richard Biener from comment #3)
> Can you maybe bisect this to a specific (fortran) commit in GCC?
This does not necessarily be a Fortran specific commit, it could also be a
change in the middle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
--- Comment #13 from Jakub Jelinek ---
Completely untested WIP patch:
--- gcc/config/i386/i386.c.jj 2020-04-27 13:50:39.529692389 +0200
+++ gcc/config/i386/i386.c 2020-04-27 14:03:12.479322957 +0200
@@ -16550,6 +16550,23 @@ ix86_is_empty_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94796
Bug ID: 94796
Summary: Failure to reuse flags from substraction
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94780
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=57359
--- Comment #30 from Richard Biener ---
Created attachment 48381
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48381&action=edit
more complex approach, POC
Another testcase, this time for store ordering (IIRC we may have a duplicate
for
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #6 from Simon Braß ---
(In reply to Richard Biener from comment #3)
> Can you maybe bisect this to a specific (fortran) commit in GCC?
FYI, I'm hooking up with the bisect (I'm a colleague of Jürgen).
I will post an update as fast as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94739
--- Comment #5 from H.J. Lu ---
(In reply to Manfred Schwarb from comment #4)
> This broke my i686 build (only, x86_64 build with same settings is OK), I get
>
> configure: error: Intel CET must be enabled on Intel CET enabled host
> make[2]: **
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94796
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94795
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94780
--- Comment #4 from Jakub Jelinek ---
Created attachment 48382
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48382&action=edit
gcc10-pr94780.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94739
--- Comment #6 from H.J. Lu ---
Created attachment 48383
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48383&action=edit
A patch.
Please try this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94797
Bug ID: 94797
Summary: libiberty doesn't demangle spaceship operator
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94798
Bug ID: 94798
Summary: Failure to optimize subtraction and 0 literal properly
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94739
Thomas Schwinge changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94799
Bug ID: 94799
Summary: [7.2+ Regression] Calling a member template function
fails
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94783
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94739
--- Comment #8 from Manfred Schwarb ---
Created attachment 48384
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48384&action=edit
libiberty/config.log
The full logfile of libiberty. I will apply the patch now and will report back.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94755
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:26d76be7af6db75aaab662f4e93395f4ff8acb38
commit r10-7989-g26d76be7af6db75aaab662f4e93395f4ff8acb38
Author: Jakub Jelinek
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94784
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94800
Bug ID: 94800
Summary: Failure to optimize yet another popcount idiom
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94801
Bug ID: 94801
Summary: Failure to optimize narrowed __builtin_clz
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94663
--- Comment #2 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #1)
> I bet IRA is confused by the subregs.
>
No, I don't think it is the case here.
(insn 19 18 20 4 (parallel [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94798
--- Comment #1 from Marc Glisse ---
(In reply to Gabriel Ravier from comment #0)
> Comparison here : https://godbolt.org/z/LZ8dBy
In your future bug reports, could you please copy all relevant information
instead of (or in addition to) linking t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94802
Bug ID: 94802
Summary: Failure to recognize identities with __builtin_clz
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94801
--- Comment #1 from Marc Glisse ---
Gcc considers that clz might return 32 on some platforms, it does not currently
use target-specific information to restrict the range of clz output.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94801
--- Comment #2 from Marc Glisse ---
if(a==0)__builtin_unreachable();
lets gcc optimize the code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94663
--- Comment #3 from Jakub Jelinek ---
(In reply to Vladimir Makarov from comment #2)
> The best way to fix is to avoid to generate such code. But I don't know is
> it possible for this case.
I'm afraid that is hard, because the Intel intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94801
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94802
--- Comment #1 from Gabriel Ravier ---
Also, there are also patterns like `__builtin_clz(a - b) == 31`, which can be
optimized to `(a - b) == 1`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94739
--- Comment #9 from Manfred Schwarb ---
Patch seems to work so far. Do you need any logfiles?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94802
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94800
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94801
--- Comment #4 from Gabriel Ravier ---
Isn't `__builtin_clz(0)` undefined ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94798
--- Comment #2 from Gabriel Ravier ---
Ok, will do that in the future. Considering I was just linking to godbolt every
time for the assembly code, should I go back to all the other bug reports that
I've made to upload assembly code there too ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94774
--- Comment #1 from Martin Sebor ---
It looks to me like only the second warning might be a true positive. The
first one seems spurious since the uninitialized access is guarded by the test
for safe being true.
Moving the guard up would suppres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94801
--- Comment #5 from Jakub Jelinek ---
In the source yes, but by the time the optimizer sees it on some targets x == 0
? 32 : __builtin_clz (x) could have been already optimized into just
__builtin_clz (x) depending on what the target macros say.
1 - 100 of 201 matches
Mail list logo
