TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (@2)) supposed to check
integer type but not pointer type, so use second parameter instead.
i.e. first parameter is VPTR, second parameter is I4.
582DEF_SYNC_BUILTIN (BUILT_IN_ATOMIC_FETCH_OR_4,
583 "__atomic_fetch_or_4",
584
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103422
Bug ID: 103422
Summary: -march=bogus12323123423452345 -march=armv8-a is
accepted
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
On Wed, 24 Nov 2021, Martin Sebor wrote:
> On 11/24/21 8:21 AM, Richard Biener via Gcc-patches wrote:
> > This resurrects -Wunreachable-code and implements a warning for
> > trivially unreachable code as of CFG construction. Most problematic
> > with this is the C/C++ frontend added 'return 0;'
On Wed, Nov 24, 2021 at 09:45:16AM +0100, Richard Biener wrote:
> > Thinking more about it, perhaps we could do more for BIT_XOR_EXPR.
> > We could allow masked1 == masked2 case for it, but would need to
> > do something different than the
> > n->n = n1->n | n2->n;
> > we do on all the bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103420
Andrew Pinski changed:
What|Removed |Added
Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103421
--- Comment #1 from Andrew Pinski ---
Only the last march is passed down to cc1 which does the verification of the
option :).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103421
Bug ID: 103421
Summary: -march=bogus12323123423452345 -march=skylake-avx512 is
accepted as a command line option
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940
Bug 98940 depends on bug 102611, which changed state.
Bug 102611 Summary: [C++23] P2128R6 - Multidimensional subscript operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102611
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102611
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101180
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8e86218f05c1a866b43ae5af3e303f91fb6d7ff0
commit r12-5511-g8e86218f05c1a866b43ae5af3e303f91fb6d7ff0
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
--- Comment #9 from Richard Biener ---
In particular MOVE_RATIO only looks applicable if the target (or RTL
expansion?) would split the bigger GIMPLE move into pieces honoring MOVE_MAX.
Though technically even MOVE_MAX only guarantees:
"The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102611
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b38c9cf6d570f6c4c1109e00c8b81d82d0f24df3
commit r12-5510-gb38c9cf6d570f6c4c1109e00c8b81d82d0f24df3
Author: Jakub Jelinek
Date:
On Wed, 24 Nov 2021, Jason Merrill wrote:
> On 11/24/21 11:15, Marek Polacek wrote:
> > On Wed, Nov 24, 2021 at 04:21:31PM +0100, Richard Biener via Gcc-patches
> > wrote:
> >> This resurrects -Wunreachable-code and implements a warning for
> >> trivially unreachable code as of CFG construction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103420
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103420
Bug ID: 103420
Summary: libatomic fails to compile on aarch64 linux with
TFLAGS="-mcpu=octeontx2"
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103416
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103412
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
--- Comment #7 from rguenther at suse dot de ---
On Thu, 25 Nov 2021, crazylht at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
>
> --- Comment #6 from Hongtao.liu ---
> (In reply to Hongtao.liu from comment #5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44011
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |5.0
Resolution|---
On Thu, Nov 25, 2021 at 12:18 PM H.J. Lu via Gcc-patches
wrote:
>
> Replace long with int64_t to work with -mx32.
Thanks.
>
> * gcc.target/i386/pr103194-5.c: Replace long with int64_t.
> ---
> gcc/testsuite/gcc.target/i386/pr103194-5.c | 3 ++-
> 1 file changed, 2 insertions(+), 1
on 2021/11/25 下午1:17, Hongtao Liu wrote:
> On Thu, Nov 25, 2021 at 11:21 AM Kewen.Lin via Gcc-patches
> wrote:
>>
>> Hi,
>>
>> This patch is to add a test case similar to the one in i386
>> to add testing coverage for 510.parest_r hotspots.
>>
>> As evaluated, the emulated gather capability of
On Thu, Nov 25, 2021 at 11:21 AM Kewen.Lin via Gcc-patches
wrote:
>
> Hi,
>
> This patch is to add a test case similar to the one in i386
> to add testing coverage for 510.parest_r hotspots.
>
> As evaluated, the emulated gather capability of vectorizer
> (r12-2733) can help to speed up SPEC2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103419
--- Comment #3 from Hongtao.liu ---
(In reply to H.J. Lu from comment #2)
> Created attachment 51871 [details]
> A patch
>
> Hongtao, please take a look.
Yes, i'll use type of second parameter which should be integer type.
Replace long with int64_t to work with -mx32.
* gcc.target/i386/pr103194-5.c: Replace long with int64_t.
---
gcc/testsuite/gcc.target/i386/pr103194-5.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/pr103194-5.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103419
--- Comment #2 from H.J. Lu ---
Created attachment 51871
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51871=edit
A patch
Hongtao, please take a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103419
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47256
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.0
--- Comment #6 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103419
Bug ID: 103419
Summary: FAIL: gcc.target/i386/pr102566-10b.c with -mx32
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93453
--- Comment #8 from HaoChen Gui ---
I refined the patch and put all things in a helper - change_pseudo_and_mask. As
you mentioned, it's still a band-aid. The perfect solution might be a better
version of nonzero_bits. Thanks.
diff --git
Hi,
This patch is to add a test case similar to the one in i386
to add testing coverage for 510.parest_r hotspots.
As evaluated, the emulated gather capability of vectorizer
(r12-2733) can help to speed up SPEC2017 510.parest_r on
Power8/9/10 by 5% to 9% with option sets Ofast unroll and
Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103404
--- Comment #5 from Tamar Christina ---
This is a somewhat latent bug in CSE where merge_equiv_classes assumes that all
entries into the equivalence table are unique but CSE makes no attempt to
enforce this constraint.
So inserting the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103417
--- Comment #5 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 51870 [details]
> gcc12-pr103417.patch
>
> Untested fix. Handling GE in that simplification is clearly bogus, we
> should just fold it to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103401
--- Comment #4 from Marek Polacek ---
I think the patch might be just:
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -7508,6 +7508,8 @@ cp_parser_postfix_expression (cp_parser *parser, bool
address_p, bool cast_p,
looking at a
On 11/24/21 03:16, Jakub Jelinek wrote:
On Fri, Nov 19, 2021 at 10:40:50AM -0500, Jason Merrill wrote:
Shall we also change the function so that it doesn't call
cplus_decl_attributes if late_attrs is NULL [...]?
Please.
Here it is.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok
On 11/24/21 08:37, Jakub Jelinek wrote:
On Tue, Nov 23, 2021 at 10:28:48PM -0500, Jason Merrill wrote:
Thanks.
+ while (true)
+ {
+ cp_expr expr (NULL_TREE);
+ /* Parse the next assignment-expression. */
+ if (cp_lexer_next_token_is
On 11/24/21 11:15, Marek Polacek wrote:
On Wed, Nov 24, 2021 at 04:21:31PM +0100, Richard Biener via Gcc-patches wrote:
This resurrects -Wunreachable-code and implements a warning for
trivially unreachable code as of CFG construction. Most problematic
with this is the C/C++ frontend added
When the optional size-index argument to attribute index is
omitted for a pointer, GCC expects the actual pointer argument
to point to an object at least as big as its size implies, or
at least one byte for void*. This is done to make it possible
to detect past-the-end accesses in calls to
On 11/24/21 17:42, Jakub Jelinek wrote:
On Wed, Nov 24, 2021 at 05:15:51PM -0500, Jason Merrill wrote:
+case CALL_EXPR:
+ if (tree fndecl = cp_get_callee_fndecl_nofold (stmt))
+ if (DECL_IMMEDIATE_FUNCTION_P (fndecl)
+ && source_location_current_p (fndecl))
+ {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103414
--- Comment #4 from kargl at gcc dot gnu.org ---
This fixes/catches the type mismatch in the issue raised in comment #1.
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 705d2326a29..0a864da015b 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
--- Comment #6 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #5)
> (In reply to Richard Biener from comment #3)
> > (In reply to H.J. Lu from comment #2)
> > > (In reply to Richard Biener from comment #1)
> > > > It isn't the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103409
--- Comment #1 from Andrew Pinski ---
The two main changes during that time period was jump threading and modref.
modref seems might be more likely with wrf being fortran code and even using
nested functions and such.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103414
--- Comment #3 from kargl at gcc dot gnu.org ---
The patch in comment #2 does not address the issue in comment #1.
The patch only address an invalid BOZ in a structure constructor.
The issue in comment #1 is technical unrelated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103414
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103409
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103407
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-11-25
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103386
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Summary|stage1 with PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103401
--- Comment #3 from Marek Polacek ---
This is trickier than it seemed.
void f(decltype(auto(0))) { }
is actually valid in C++23 (probably) since auto(x) is supported. So I think
it's essentially like
void f(int) { }
The r11-1913 change is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100687
Johel Ernesto Guerrero Peña changed:
What|Removed |Added
CC||johelegp at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103415
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103244
--- Comment #4 from test test ---
(test, ignore)
Changes since v6[6] and v5[5]:
- Based this version on the v5 one.
- Reworked all builtins back to the way they are in v5 and added the
following changes:
+ Added a test to target libc, only expanding with glibc as the
target libc.
+ Updated all three expanders header comment
On Wed, Sep 15, 2021 at 4:12 AM CHIGOT, CLEMENT wrote:
>
> As gcc on 64bit for AIX is built with "MULTILIB_MATCHES= .=maix32",
> "-print-multi-directory" and similar flags aren't returning the
> correct directory when used with -maix32: "." is returned instead
> of "ppc32".
> Libgcc installation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102239
--- Comment #3 from Segher Boessenkool ---
(In reply to luoxhu from comment #2)
> (In reply to Segher Boessenkool from comment #1)
> > Confirmed.
> >
> > So the relevant insn
> >
> > (parallel [(set (reg:CC 123)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
> index 2bf21434a42..971c2fa1dd6 100644
> --- a/gcc/fortran/match.c
> +++ b/gcc/fortran/match.c
> @@
On 11/24/2021 12:41 PM, Zdenek Sojka wrote:
Hello Jeff,
-- Původní e-mail --
Od: Jeff Law via Gcc
Komu: Paul Floyd , gcc@gcc.gnu.org
Datum: 24. 11. 2021 20:33:02
Předmět: Re: distinguishing gcc compilation valgrind false positives
On 11/24/2021 12:15 PM, Paul Floyd
On 11/24/2021 2:19 PM, Navid Rahimi via Gcc wrote:
Hi GCC community,
I have a question about pattern matching in match.pd.
So I have a pattern like this [1]:
#define CMP !=
bool f(bool c, int i) { return (c << i) CMP 0; }
bool g(bool c, int i) { return c CMP 0;}
It is verifiably correct to
On Wed, Nov 24, 2021 at 05:15:51PM -0500, Jason Merrill wrote:
> > +case CALL_EXPR:
> > + if (tree fndecl = cp_get_callee_fndecl_nofold (stmt))
> > + if (DECL_IMMEDIATE_FUNCTION_P (fndecl)
> > + && source_location_current_p (fndecl))
> > + {
> > + tree fn = cp_get_callee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387
Tulio Magno Quites Machado Filho changed:
What|Removed |Added
CC||tuliom at ascii dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103406
--- Comment #11 from joseph at codesourcery dot com ---
The sign of a NaN result is never specified in C except for fabs,
copysign, negation, unary + (and assignment to the same format in the case
where that's copy rather than convertFormat).
On 11/24/21 13:02, Jakub Jelinek wrote:
On Wed, Nov 24, 2021 at 05:02:03PM +0100, Jakub Jelinek via Gcc-patches wrote:
Unfortunately, the location wrappers are optimized away before we get a
chance to use them in cp_fold_r.
So, on the following patch, we get the location right on PTRMEM_CSTs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103382
--- Comment #4 from Jonathan Wakely ---
Yes, it's just a lot of work to implement correctly, and non-zero overhead to
change the cancellation state.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418
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=103414
G. Steinmetz changed:
What|Removed |Added
Summary|[PDT] [10/11/12 Regression] |[PDT] ICE in
|ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103417
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103392
--- Comment #7 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:56b3036c531929e0dae1103b9f5d20c82643415f
commit r11-9308-g56b3036c531929e0dae1103b9f5d20c82643415f
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102718
Thomas Schwinge changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103411
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
On Wed, Nov 24, 2021 at 05:22:57PM -0300, Raoni Fassina Firmino wrote:
> Hi Joseph,
>
> Thanks for the detailed review and explanations.
>From me as well :-)
> On Mon, Oct 18, 2021 at 03:54:53PM +, Joseph Myers wrote:
> > However, it's better to get things right automatically without
Dear all,
when checking the SOURCE and SHAPE arguments to the RESHAPE
intrinsic, for absent PAD argument we failed to handle the case
when SHAPE was a parameter.
Fortunately, the proper check was already there, and the code
just needs some tweaking, as well as one of the testcases.
Regtested on
Hi,
this patch fixes wrong code issue where modref did not propagate flags
for static chain in ipa_merge_modref_summary_after_inlininig. It is a
place I missed to update in original patch extending return slot
tracking to static chain. Unlike return slot we need to propagate flags
here (return
Hi!
On 2021-11-24T20:05:56+0100, Zdenek Sojka via Gcc wrote:
> from time to time, I come upon a testcase that failed during the automated
> runs, but passes during reduction; there are valgrind warnings present,
> however.
Thanks for looking into this. Please collect any Valgrind notes at
Hi GCC community,
I have a question about pattern matching in match.pd.
So I have a pattern like this [1]:
#define CMP !=
bool f(bool c, int i) { return (c << i) CMP 0; }
bool g(bool c, int i) { return c CMP 0;}
It is verifiably correct to transfer f to g [2]. Although this pattern looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103417
--- Comment #3 from Jakub Jelinek ---
generic_simplify_GE_EXPR is called with
BIT_FIELD_REF & 4294967040U
and
0U
arguments, and transforms that into
BIT_FIELD_REF <= 255. That is wrong,
(BIT_FIELD_REF & 4294967040U) >= 0U
is always true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103417
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103417
Andrew Pinski changed:
What|Removed |Added
Version|unknown |12.0
Summary|wrong code at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103417
--- Comment #1 from Andrew Pinski ---
It worked at r12-5485-ge1d4359264585
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418
Bug ID: 103418
Summary: random_number() does not accept pointer, intent(in)
array argument
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103411
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211124 (experimental) [master r12-5505-g5deacf6058d] (GCC)
[558] %
[558] % gcctk -O0 small.c; ./a.out
[559] %
[559] % gcctk -O1 small.c
[560] % ./a.out
Aborted
[561] %
[561] % cat small.c
struct {
int a : 8;
int b : 24;
} c = {0, 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
--- Comment #4 from John S ---
I can Confirm from my side that it does appear to be the memmove inline
expansion and not the auto vectorizer. It also occurs with
builtin_memset/builtin_memcpy as well.
For some context, this is an issue would
Hi Joseph,
Thanks for the detailed review and explanations.
On Mon, Oct 18, 2021 at 03:54:53PM +, Joseph Myers wrote:
> However, it's better to get things right automatically without needing any
> macros or other header additions at all. That is, define feclearexcept as
> a built-in
Hi
the main reason why it looks like a false positive is that I've had
these valgrind warnings ... since probably ever, but it was never
causing issues.
I cannot tell from the sources if there is anything wrong, so I am
better asking here.
Well, that's the nature of undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87851
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #18 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87711
--- Comment #6 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:3e6b9910e8e23d690fa1026b2879d37745ddd740
commit r11-9307-g3e6b9910e8e23d690fa1026b2879d37745ddd740
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87851
--- Comment #17 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:3e6b9910e8e23d690fa1026b2879d37745ddd740
commit r11-9307-g3e6b9910e8e23d690fa1026b2879d37745ddd740
Author: Harald Anlauf
PHI nodes frequently feed each other, and this is particularly true of
the one/two incoming edge PHIs inserted by some of the loop analysis
code which is introduced at the start of the VRP passes.
Ranger has a hybrid of optimistic vs pessimistic evaluation, and when it
switches to
> ==5404== Conditional jump or move depends on uninitialised value(s)
> ==5404== at 0x25DAAD7: incorporate_penalties (ipa-cp.c:3282)
> ==5404== by 0x25DAAD7: good_cloning_opportunity_p(cgraph_node*, sreal,
> sreal, profile_count, int) (ipa-cp.c:3340)
I looked at this one (since it is in
On 11/24/2021 7:24 AM, Thomas Schwinge wrote:
Hi!
On 2021-07-30T15:58:36+0800, "Kewen.Lin" wrote:
on 2021/7/30 下午3:18, Thomas Schwinge wrote:
Curious why in some instances we're not removing the 'class loop *loop'
declaration, I had a look, and this may suggest some further clean-up?
Hello Jeff,
-- Původní e-mail --
Od: Jeff Law via Gcc
Komu: Paul Floyd , gcc@gcc.gnu.org
Datum: 24. 11. 2021 20:33:02
Předmět: Re: distinguishing gcc compilation valgrind false positives
"
On 11/24/2021 12:15 PM, Paul Floyd via Gcc wrote:
>
> On 24/11/2021 20:05, Zdenek Sojka
On Wed, Nov 24, 2021 at 12:31:53PM -0700, Jeff Law via Gcc wrote:
> Agreed. Work from the assumption it's a real GCC issue until proven
> otherwise.
>
> I believe GCC has annotations to help valgrind that are turned on by a magic
> configuration option as well.
True, but Zdenek has them turned
Hello Paul,
(sorry for re-post, I didn't include the ML in the original reply)
-- Původní e-mail --
Od: Paul Floyd via Gcc
Komu: gcc@gcc.gnu.org
Datum: 24. 11. 2021 20:16:33
Předmět: Re: distinguishing gcc compilation valgrind false positives
"
On 24/11/2021 20:05, Zdenek Sojka
On 11/24/2021 12:15 PM, Paul Floyd via Gcc wrote:
On 24/11/2021 20:05, Zdenek Sojka via Gcc wrote:
Hello,
from time to time, I come upon a testcase that failed during the
automated
runs, but passes during reduction; there are valgrind warnings present,
however. How do I distinguish what
On 24/11/2021 20:05, Zdenek Sojka via Gcc wrote:
Hello,
from time to time, I come upon a testcase that failed during the automated
runs, but passes during reduction; there are valgrind warnings present,
however. How do I distinguish what warnings are valid and which are false
positives? Is
On Wed, Nov 24, 2021 at 10:22 AM Richard Biener via Gcc-patches
wrote:
>
> This resurrects -Wunreachable-code and implements a warning for
> trivially unreachable code as of CFG construction. Most problematic
> with this is the C/C++ frontend added 'return 0;' stmt in main
> which the patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92479
Eric Gallager changed:
What|Removed |Added
Status|SUSPENDED |NEW
CC|
1 - 100 of 304 matches
Mail list logo
