[Bug bootstrap/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 Andrew Pinski changed: What|Removed |Added Keywords||build, wrong-code Status|NEW |WAITING --- Comment #2 from Andrew Pinski --- (In reply to Martin Liška from comment #1) > Created attachment 47974 [details] > Reduced test-case I doubt this is a reduced testcase. It is a reduced testcase for the ICE but not the wrong code causing the ICE, see your comment below ... (In reply to Martin Liška from comment #0) > I can't reproduce that with a cross compiler and I noticed that one needs > to bootstrap compiler. --disable-bootstrap seems fine. I don't have a handy > machine where I could reproduce that right now.. So if you use --disable-bootstrap, did you run the testsuite? That sometimes will find which testcase is producing wrong code now. The other way to find what is being miscompiled is bisect the commit which introduced the problem and then compare the .o files for the stage which is being compiled. Note you also attached the incorrect log file. it is a log for building hfst-ospell
[Bug bootstrap/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #3 from Andrew Pinski --- One question I have is which stage fails? Is it stage 2 or stage 3? Because if it is stage 3, then stage 2 is miscompiled which is causing a different miscompile in stage 3.
[Bug bootstrap/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > One question I have is which stage fails? Is it stage 2 or stage 3? > Because if it is stage 3, then stage 2 is miscompiled which is causing a > different miscompile in stage 3. With the proper log file, it is stage 2 GCC that is producing the ICE. This makes it a little easier to debug :).
[Bug tree-optimization/92645] Hand written vector code is 450 times slower when compiled with GCC compared to Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
--- Comment #22 from Andrew Pinski ---
(In reply to Richard Biener from comment #20)
> where SLP vectorization is confused about (char) _19 vs. BIT_FIELD_REF
> but also wouldn't handle BIT_FIELD_REFs. It neither vectorizes the
> store to a store from a CTOR which forwprop could then pattern-match.
I ran into the issue of (cast) _1 also. I had a function which finds BFRs and
treated the cast to a lower precision as a BFR:
/* Find a BIT_FIELD_REF from the ssa is defined by.
Expand the BIT_FIELD_REF to BITPOS, BITSIZE and OUTERSIZE. Returning
the inner value of the BIT_FIELD_REF. */
tree
ssa_name_to_BFR (tree value, unsigned HOST_WIDE_INT &bitpos,
unsigned HOST_WIDE_INT &bitsize,
unsigned HOST_WIDE_INT &outersize)
{
if (TREE_CODE (value) != SSA_NAME)
return NULL;
gimple *def = SSA_NAME_DEF_STMT (value);
if (stmt_could_throw_p (cfun, def)
|| !is_gimple_assign (def))
return NULL;
/* Treat a normal cast as extracting the lower bits of the inner value. */
if (CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def)))
{
tree inner = gimple_assign_rhs1 (def);
tree outer_type = TREE_TYPE (value);
tree inner_type = TREE_TYPE (inner);
if (!INTEGRAL_TYPE_P (outer_type)
|| !INTEGRAL_TYPE_P (inner_type))
return NULL;
outersize = TYPE_PRECISION (inner_type);
bitsize = TYPE_PRECISION (outer_type);
if (outersize <= bitsize)
return NULL;
gimple_set_visited (def, true);
bitpos = 0;
return inner;
}
if (gimple_assign_rhs_code (def) != BIT_FIELD_REF)
return NULL;
tree bfr = gimple_assign_rhs1 (def);
/* Make sure the BIT_FIELD_REF is acting on a SSA_NAME.
Cannot handle an memory value. */
if (TREE_CODE (TREE_OPERAND (bfr, 0)) != SSA_NAME)
return NULL;
bitsize = tree_to_uhwi (TREE_OPERAND (bfr, 1));
bitpos = tree_to_uhwi (TREE_OPERAND (bfr, 2));
tree otype = TREE_TYPE (TREE_OPERAND (bfr, 0));
if (INTEGRAL_TYPE_P (otype))
outersize = TYPE_PRECISION (otype);
else
outersize = tree_to_uhwi (TYPE_SIZE (otype));
if (INTEGRAL_TYPE_P (otype) && BYTES_BIG_ENDIAN)
bitpos = outersize - bitsize - bitpos;
/* Mark the statement as visited as we might remove the
reference to it later on. */
gimple_set_visited (def, true);
return TREE_OPERAND (bfr, 0);
}
[Bug c/94055] Segmentation fault in memet function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94055 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- Stack is limited. See ulimit on unix shell.
[Bug c/94053] Segmentation fault in default Optimization, but works well in O1 ~ Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94053 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- The code is undefined so both behaviors are fine. Note address sanitizer will dect this at runtime.
[Bug target/94054] wrong inliine asm generated for 'w' constraint on neon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94054
--- Comment #1 from Andrew Pinski ---
You need to use the operand modifier P here:
__asm__ __volatile__ (
"vld1.f32 {d0,d1}, [%[src]]! \n\t"
"vtbl.8 d2, {d0,d1}, %P[t0] \n\t"
"vtbl.8 d3, {d0,d1}, %P[t1] \n\t"
"vst1.s16 {d2,d3}, [%[dst]]! \n\t"
: [dst] "+r" (dst), [src] "+r" (src)
: [t0] "w" (t0), [t1] "w" (t1)
: "memory", "d0", "d1", "d2", "d3"
);
t0 could be stored in s0..s14 and GCC defaults to printing out s0..s14. Note
those registers map to d0..d7 also.
Now the operand modifiers are not documented for ARM. There might be another
bug about this too.
[Bug target/94054] wrong inliine asm generated for 'w' constraint on neon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94054 --- Comment #2 from Andrew Pinski --- related to PR PR 84343.
[Bug target/94054] wrong inliine asm generated for 'w' constraint on neon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94054 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 37188 which talks about the need for the documentation of 'q' and 'P' operand modifiers. *** This bug has been marked as a duplicate of bug 37188 ***
[Bug inline-asm/37188] Missing documentation about the use of ARM NEON quad registers in inline asm arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37188 Andrew Pinski changed: What|Removed |Added CC||raj.khem at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 94054 has been marked as a duplicate of this bug. ***
[Bug target/94052] Paradoxical subregs out of expand causes ICE with multi register modes at -O2 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94052 Andrew Pinski changed: What|Removed |Added Blocks||89967 --- Comment #2 from Andrew Pinski --- Related to PR 89967. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89967 [Bug 89967] Inefficient code generation for vld2q_lane_u8 under aarch64
[Bug target/94052] Paradoxical subregs out of expand causes ICE with multi register modes at -O2 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94052 Andrew Pinski changed: What|Removed |Added Blocks||89057 --- Comment #3 from Andrew Pinski --- and PR 89057. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89057 [Bug 89057] [8/9/10 Regression] AArch64 ld3 st4 less optimized
[Bug target/89967] Inefficient code generation for vld2q_lane_u8 under aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89967 Andrew Pinski changed: What|Removed |Added Depends on||89057 --- Comment #2 from Andrew Pinski --- Related to PR 89057. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89057 [Bug 89057] [8/9/10 Regression] AArch64 ld3 st4 less optimized
[Bug target/94052] Paradoxical subregs out of expand causes ICE with multi register modes at -O2 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94052 --- Comment #4 from Andrew Pinski --- (In reply to Tamar Christina from comment #1) > I don't believe this ever worked.. At least testing 8,9 and 10 all ICE. So I > didn't put a regression label on it. (and couldn't figure out the format for > known-to-fail). Hmm, could this work on GCC 7? https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01974.html changed how this was handled too.
[Bug middle-end/79755] [8/9/10 Regression] ICE: segfault in cgraph_node::get, at cgraph.h:1261
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79755 Andrew Pinski changed: What|Removed |Added Keywords||ice-checking --- Comment #11 from Andrew Pinski --- (In reply to Nicholas Krause from comment #8) > test.c:1: confused by earlier errors, bailing out > > So no it does not appear to segfault on 9.2 not sure about trunk. YES it does. Just GCC is being smart here when configured with --enable-checking=release (the default for releases) and just prints out "confused by earlier errors, bailing out" for all ICEs after an error has happened. This is why Jakub's comment #7: "This does happen even with 9.2 and current trunk, you just need to read the first line in #c0." The first line in #c0 was: Affects versions down to 4.9 (configured with --enable-checking=yes) Which means you need --enable-checking=yes (and not --enable-checking=release) to get the full ICE happening.
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #16 from Andrew Pinski --- (In reply to Martin Liška from comment #15) > Started with r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9. This should just change the costs of the register usage. Which means it might be a latent bug before this patch.
[Bug target/94059] [10 Regression] m68k: Bootstrap fails configuring libiberty with 'cannot compute sizeof (long long)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94059 Andrew Pinski changed: What|Removed |Added Keywords||build, wrong-code Target Milestone|--- |10.0
[Bug c++/94064] O0 vs O1/O2/O3 different output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94064 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- https://gcc.gnu.org/gcc-6/porting_to.html More aggressive optimization of -flifetime-dse This includes inplacement new operator.
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #20 from Andrew Pinski --- The return value of the first _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 was being copied into r8 and then copied back into r3 (return value), but not r0 is used and that r0 is used for mtlr (moving back the return address).
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #24 from Andrew Pinski --- (In reply to Martin Liška from comment #23) > (In reply to Andrew Pinski from comment #20) > > The return value of the first _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 was > > being copied into r8 and then copied back into r3 (return value), but not r0 > > is used and that r0 is used for mtlr (moving back the return address). > > This is the correct explanation, thanks Adrew. > > In good version >│0x104c9128 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+104> bl > 0x1049f300 <._Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0> > > sets return value to $r3, which is then returned ($r8 = $r3, $r3 = $r8): > (gdb) p /x $r3 > $60 = 0x3fffaf3814d0 > > while in bad version we return value of: >│0x104c9134 <._Z19tsubst_template_argP9tree_nodeS0_iS0_+116> mtlr > r0 > (gdb) p /x $r3 > $31 = 0x104c92a4 > > which is the return address (can be seen in back-trace). Note I bet after LRA, there is a move between r0 and r3 after the call to _Z11tsubst_exprP9tree_nodeS0_iS0_b.part.0 but it gets removed as r0 is clobbered by the load. So we need to understand why LRA/IRA assigns the r_5/_34/_21 as r0 and then what also decides to use r0 for load/storing the LR.
[Bug middle-end/94083] inefficient soft-float x!=Inf code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |minor --- Comment #1 from Andrew Pinski --- Most people don't use soft-float these days except for the low-end embedded folks. And even then, the low-end embedded folks try to avoid floating point. So I don't know many people who cares about soft-float.
[Bug libstdc++/94080] -mabi=ieeelongdouble and -mfloat128 cause libstc++ header breakage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94080 Andrew Pinski changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #1 from Andrew Pinski --- I suspect you need to configure gcc originally to use that abi. Otherwise libstdc++ config header is not correct.
[Bug tree-optimization/94084] Optimizer produces suboptimal code related to loop-invariant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94084 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|tree-optimization Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- dest could alias base in the first case. Though it could only be if n == 1,
[Bug c/94075] When using linker-generated list, bad optimization performed in -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94075
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Andrew Pinski ---
GCC think incrementing start will never get to end.
So you need to hide that from GCC.
The best way is doing:
({ static const int foo[0] __attribute__((aligned(4), section(".foo_1")));
const int *a = &foo[0]; __asm__("":"+r"(a)); a});
libgcc does that in crtstuff.c:
fn = _ITM_deregisterTMCloneTable;
__asm ("" : "+r" (fn));
[Bug target/94042] [10 Regression] Bootstrap fails on ppc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94042 --- Comment #35 from Andrew Pinski --- (In reply to Martin Liška from comment #15) > Started with r10-6919-gf3ce088645e5305d932380c7520809181b2d2eb9. This change goes against what HONOR_REG_ALLOC_ORDER is documented on doing (I Mean the false case of HONOR_REG_ALLOC_ORDER): Normally, IRA tries to estimate the costs for saving a register in the prologue and restoring it in the epilogue. This discourages it from using call-saved registers. If a machine wants to ensure that IRA allocates registers in the order given by REG_ALLOC_ORDER even if some call-saved registers appear earlier than call-used ones, then define this macro as a C expression to nonzero. Default is 0. Since r8 is still a caller-saved register, HONOR_REG_ALLOC_ORDER should not make a difference here. The order for rs6000 is: MAYBE_R2_AVAILABLE \ 9, 10, 8, 7, 6, 5, 4,\ 3, EARLY_R12 11, 0, \ Still that should apply here rather than register number based. Really doing cost based on register # seems incorrect anyways. These are all caller-saved registers IIRC. r0 is special in rs6000 where it sometimes cannot show up; e.g. base+reg base cannot be r0.
[Bug tree-optimization/94084] Optimizer produces suboptimal code related to loop-invariant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94084 --- Comment #3 from Andrew Pinski --- (In reply to vfdff from comment #2) > thanks very much, you are right. The same problem is here.
[Bug c++/85079] Segfault While Compiling DXX-Rebirth Project
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85079 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED
[Bug target/78636] PPC Optimization Bug in Libelemental unit test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78636 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED Component|c++ |target
[Bug tree-optimization/94086] Missed optimization when converting a bitfield to an integer on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94086 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Severity|normal |enhancement Component|c |tree-optimization
[Bug target/94087] std::random_device often fails when used from multiple threads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > >The bug is *not* present on on Fedora:31 where the compiler reports: > > I doubt it is version based but rather based on what the CPU you are running > on. I Mean what type of CPU you are running on.
[Bug target/94087] std::random_device often fails when used from multiple threads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087 --- Comment #1 from Andrew Pinski --- >The bug is *not* present on on Fedora:31 where the compiler reports: I doubt it is version based but rather based on what the CPU you are running on.
[Bug target/94087] std::random_device often fails when used from multiple threads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087 --- Comment #3 from Andrew Pinski --- https://software.intel.com/sites/default/files/managed/98/4a/DRNG_Software_Implementation_Guide_2.1.pdf 5.3.1 Retry Recommendations ... If only one thread is calling RDSEED infrequently, it is very unlikely that a random seed will not be available. Only during periods of heavy demand, such as when one thread is calling RDSEED in rapid succession or multiple threads are calling RDSEED simultaneously, are underflows likely to occur. ... 5.3.1.2 Asynchronous applications The application should be prepared to give up on RDSEED after a small number of retries, where "small" is somewhere between 1 and 100, depending on the application's sensitivity to delays. As with synchronous applications, it is recommended that a PAUSE instruction be inserted into the retry loop. Applications needing a more aggressive approach can alternate between RDSEED and RDRAND, pulling seeds from RDSEED as they are available and filling a RDRAND buffer for future 512:1 reduction when they are not. CUT ---
[Bug bootstrap/94089] fixincludes of breaks gcc after glibc-2.31 upgrade
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94089 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- If you use a gcc with a different glibc, you need to rerun fixincludes. Fixincludes is installed too.
[Bug tree-optimization/94092] Code size and performance degradations after -ftree-loop-distribute-patterns was enabled at -O[2s]+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092 --- Comment #1 from Andrew Pinski --- >For coremark, this is not only harmful to performance, but also code size. Bad, very bad benchmark SPEC CPU is closer to real code but still bad benchmarks.
[Bug tree-optimization/94092] Code size and performance degradations after -ftree-loop-distribute-patterns was enabled at -O[2s]+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > >For coremark, this is not only harmful to performance, but also code size. > > > Bad, very bad benchmark Coremark only handles very very small data sets by default. I think you should run your real code over this and see if it improves or not. Also -O2 does not care exactly about code size, that -Os only. Can you provide a test where besides coremark which decreases in performance and increase in size?
[Bug tree-optimization/94092] Code size and performance degradations after -ftree-loop-distribute-patterns was enabled at -O[2s]+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94092 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2020-03-09
[Bug target/94093] -malign-double changes alignment of double type only and not long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94093 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2020-03-09 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||ABI, wrong-code --- Comment #1 from Andrew Pinski --- Better testcase which fails at compile time (and is GNU++98 rather than C++11). typedef int aligndoubletest[__alignof__(double) != 4 ? 1 : -1]; typedef int alignlongdoubletest[__alignof__(long double) != 4 ? 1 : -1]; But it has been wrong since 4.1.2 so I doubt anyone is going to fix this.
[Bug target/94093] -malign-double changes alignment of double type only and not long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94093 --- Comment #2 from Andrew Pinski --- This might be just like PR 47120.
[Bug target/94095] Modifier 'a' do not work as described
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94095 --- Comment #1 from Andrew Pinski --- The problem is just 'a' in the first (Modifier) column is wrong, it should have been 'A'. I will commit the patch in a few minutes. Operand column is correct to use 'A'.
[Bug target/94095] Modifier 'a' do not work as described
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94095 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |10.0 Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Fixed for GCC 10. If someone else wants to backport the patch (it is trival), I am ok with it.
[Bug middle-end/94103] Wrong optimization: reading value of a variable changes its representation for optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94103 --- Comment #2 from Andrew Pinski --- long double has padding bits on x86_64 so that is not shocking there. _Decimal3 is a different issue all together.
[Bug inline-asm/94113] Apparently incorrect register allocation in inline asm when using CMOV.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94113
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Andrew Pinski ---
You need an early clobber:
__asm__ volatile("movl %3, %0;\n\t" \
"cmpl $0, %1;\n\t" \
"cmovne %2, %0;\n\t" \
: "=&r"(final_result) \
: "r"(cond), "r"(if_true), "r"(if_false) \
: "cc" \
);
Otherwise GCC thinks 0th operand and the second operand can be in the same
register. With the early clobber it basically says the 0th operand cannot be
the same register as the other ones.
[Bug inline-asm/31386] wrong registers used in cmov instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31386 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- Invalid as mentioned, you need the early clobbers, otherwise GCC thinks the output and input registers can be the same. In this case the output registers which is held in operand 0 has to be different from operands 4 and 5.
[Bug c++/94067] [10 Regression] ICE on rotate with -Wconversion since r10-6527
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94067 Andrew Pinski changed: What|Removed |Added CC||antonio.di.monaco at sap dot com --- Comment #4 from Andrew Pinski --- *** Bug 94116 has been marked as a duplicate of this bug. ***
[Bug c++/94116] GCC regression - unexpected AST of kind lrotate_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94116 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Fixed yesterday. See PR 94067 *** This bug has been marked as a duplicate of bug 94067 ***
[Bug tree-optimization/94125] [9/10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94125 Andrew Pinski changed: What|Removed |Added Summary|wrong code at -O3 on|[9/10 Regression] wrong |x86_64-linux-gnu|code at -O3 on ||x86_64-linux-gnu Keywords||wrong-code Version|unknown |10.0 Target Milestone|--- |9.3
[Bug web/94118] Undocumented inline assembly [target] operand modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94118 Andrew Pinski changed: What|Removed |Added Depends on||37188 --- Comment #1 from Andrew Pinski --- ARM is recorded as PR 37188. There might other bug report for other targets too. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37188 [Bug 37188] Missing documentation about the use of ARM NEON quad registers in inline asm arguments
[Bug rtl-optimization/94133] GCC loses track of SHIFT optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94133
--- Comment #2 from Andrew Pinski ---
In the first example combine is able to combine:
Trying 13 -> 14:
13: {r96:SI=r103:SI&0x3f;clobber flags:CC;}
REG_DEAD r103:SI
REG_UNUSED flags:CC
14: {r97:TI=r95:TI<
[Bug c++/94132] Valid usage of flexible array member failing to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94132 --- Comment #1 from Andrew Pinski --- >Can we make this check more robust so valid usage isn't rejected? Why do you think it is valid?
[Bug target/94133] GCC loses track of SHIFT optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94133
Andrew Pinski changed:
What|Removed |Added
Component|rtl-optimization|target
Target||x86_64-*-*-*
--- Comment #3 from Andrew Pinski ---
Actually it is done by combine though the target cost model says it is not
profitable:
Trying 10 -> 15:
10: {r84:SI=r115:SI&0x3f;clobber flags:CC;}
REG_DEAD r115:SI
REG_UNUSED flags:CC
15: {r101:TI=r100:TI<
[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94134 Andrew Pinski changed: What|Removed |Added CC||coryan+gccbugzilla at google dot c ||om --- Comment #2 from Andrew Pinski --- *** Bug 94085 has been marked as a duplicate of this bug. ***
[Bug target/94085] pdp11-aout puts initial variable into .text section rather than .data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94085 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Done. *** This bug has been marked as a duplicate of bug 94134 ***
[Bug target/94134] pdp11-aout puts initial variable into .text section rather than .data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94134 --- Comment #3 from Andrew Pinski --- Most targets output .lcommon or similar for this case.
[Bug target/94095] Modifier 'a' do not work as described
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94095 --- Comment #4 from Andrew Pinski --- (In reply to Martin Liška from comment #3) I did not notice the git to bugzilla comment connection was not working until yesterday and then forgot to update this one. THanks for doing it.
[Bug middle-end/94146] [10 Regression] Merging functions with same bodies stopped working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94146 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #7 from Andrew Pinski --- Both functions are extern. So both functions can have their address taken out side of this TU so they cannot be alias of each other. Yes inlining inlined back the original function but that is ok because the cost model is saying that is cheaper than the call itself. Note even though the cost model could be improved, tail call detection happens late so the cost for call does not take into account tail call. Oh not every target has a tail call pattern (major ones do).
[Bug target/94158] Expanded strlen causes out-of-bounds read on AMD64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94158 --- Comment #1 from Andrew Pinski --- A pointer returned from strdup has to be valid to be able pass to free. Your testcase makes that invalid.
[Bug target/94158] Expanded strlen causes out-of-bounds read on AMD64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94158 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2020-03-12 --- Comment #2 from Andrew Pinski --- Also aligned_alloc normally does not allow alignment of 1. So GCC is doing the correct thing.
[Bug target/94158] Expanded strlen causes out-of-bounds read on AMD64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94158 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- (In reply to Parker Thompson from comment #3) > As for alloc alignment, glibc strdup() does not use aligned_alloc, just > malloc. Which by my read of the spec does not guarantee alignment. malloc requires alignement of alignof(max_align_t) (definition in the newest C and C++ standards) but beforehand it was required to be aligned enough to support all standard types.
[Bug target/94158] Expanded strlen causes out-of-bounds read on AMD64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94158 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > (In reply to Parker Thompson from comment #3) > > As for alloc alignment, glibc strdup() does not use aligned_alloc, just > > malloc. Which by my read of the spec does not guarantee alignment. > > malloc requires alignement of alignof(max_align_t) (definition in the newest > C and C++ standards) but beforehand it was required to be aligned enough to > support all standard types. C11 is where the definition changes to use max_align_t. https://en.cppreference.com/w/c/types/max_align_t
[Bug rtl-optimization/94026] combine missed opportunity to simplify comparisons with zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94026 --- Comment #3 from Andrew Pinski --- I think part of this optimization should be done on the tree level.
[Bug tree-optimization/94163] [8/9 Regression] internal compiler error: in set_ptr_info_alignment, at tree-ssanames.c:671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94163 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |8.5 Summary|internal compiler error: in |[8/9 Regression] internal |set_ptr_info_alignment, at |compiler error: in |tree-ssanames.c:671 |set_ptr_info_alignment, at ||tree-ssanames.c:671 Known to work||10.0, 7.3.0, 7.4.0 Known to fail||8.3.0, 8.4.0, 9.2.0 --- Comment #1 from Andrew Pinski --- I wonder if this is a latent bug in GCC 10.
[Bug middle-end/94172] [arm-none-eabi] ICE in expand_debug_locations, at cfgexpand.c:5403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94172 --- Comment #1 from Andrew Pinski --- >GNU Tools for Arm Embedded Processors 8-2019-q3-update You should report this to ARM really.
[Bug other/94182] Document -Wchar-subscripts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94182 --- Comment #2 from Andrew Pinski --- Considering it is documented in another place where char is signed or unsigned. I don't know if this needs to change. https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Characters-implementation.html#Characters-implementation Which of signed char or unsigned char has the same range, representation, and behavior as “plain” char (C90 6.1.2.5, C90 6.2.1.1, C99 and C11 6.2.5, C99 and C11 6.3.1.1). Determined by ABI. The options -funsigned-char and -fsigned-char change the default. See Options Controlling C Dialect. - CUT - Plus -funsigned-char/-fsigned-char
[Bug c++/94184] Global variable inline constructor elision.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94184 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization --- Comment #1 from Andrew Pinski --- There is another bug about this already.
[Bug driver/94198] Placement of source file in GCC command line has impact on whether the link succeeds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94198 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- The order of the object files and source is kept. This is by design. This is not something which is going to change because clang is broken and does not follow posix orders.
[Bug target/94200] -mabi=ibmlongdouble and -mlong-double-128 produces error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94200 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2020-03-16 --- Comment #1 from Andrew Pinski --- >This was fixed in GCC 8, and does not happen with GCC 7.4.0 GCC 7.5.0 was the last release of GCC 7.x series. Can you make sure it works with the latest GCC 8.x release? If so then this will be closed as fixed.
[Bug middle-end/94206] Wrong optimization: memset of n-bit integer types (from bit-fields) is truncated to n bits (instead of sizeof)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94206 --- Comment #1 from Andrew Pinski --- This again padding bits.
[Bug preprocessor/94207] error: pasting "::" and "ClassFOO1" does not give a valid preprocessing token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94207 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- GCC is correct here. Pasting of :: and ClassFOO1 don't make a valid preprocessing token. That is you don't need the pasting operator between :: and k here. The pasting operator is used to paste together two identifiers to make one.
[Bug preprocessor/94207] error: pasting "::" and "ClassFOO1" does not give a valid preprocessing token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94207 --- Comment #3 from Andrew Pinski --- #define ENUM_CLASS_TEST_INIT(k) \ mEnumClassTest[(int)EnumClassTest :: k] = EnumClassTest :: k;
[Bug target/94200] -mabi=ibmlongdouble and -mlong-double-128 produces error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94200 Andrew Pinski changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 Version|7.5.0 |8.4.0
[Bug middle-end/94212] [AARCH64] [Regression] Incorrect vectorization of loop with FP calculations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94212 Andrew Pinski changed: What|Removed |Added Component|c |middle-end --- Comment #1 from Andrew Pinski --- I suspect there is an Fused multiple-add being used for vectorized version while not for the non-vectorized version.
[Bug middle-end/94212] [AARCH64] [Regression] Incorrect vectorization of loop with FP calculations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94212 --- Comment #2 from Andrew Pinski --- >(at least x86_64 is fine) No, just FMA is not enabled by default. If I use -march=skylake-avx512 , I get the same answers as on aarch64_64.
[Bug middle-end/94212] Incorrect vectorization of loop with FP calculations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94212 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > >(at least x86_64 is fine) > No, just FMA is not enabled by default. > If I use -march=skylake-avx512 , I get the same answers as on aarch64_64. Note I am running on Intel(R) Xeon(R) D-2146NT CPU @ 2.30GHz.
[Bug middle-end/94212] Incorrect vectorization of loop with FP calculations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94212 --- Comment #4 from Andrew Pinski --- Note also using -ffp-contract=off will also change the value.
[Bug target/94218] Different __builtin_setjmp/__builtin_longjmp buffer layout is suggested in case of cet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94218 --- Comment #2 from Andrew Pinski --- __builtin_setjmp/__builtin_longjmp really should not be used. They are normally used internally for Exception handling if dwarf2 eh is not enabled.
[Bug target/94218] Different __builtin_setjmp/__builtin_longjmp buffer layout is suggested in case of cet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94218 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- "This can make __builtin_setjmp and __builtin_longjmp more efficient than their library counterparts in some cases, but it can also cause incorrect and mysterious behavior when mixing with code that uses the full register set."
[Bug target/94218] Different __builtin_setjmp/__builtin_longjmp buffer layout is suggested in case of cet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94218 --- Comment #3 from Andrew Pinski --- https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Nonlocal-Gotos.html#index-_005f_005fbuiltin_005fsetjmp "You should use the standard C library functions declared in in user code instead of the builtins"
[Bug target/94218] Different __builtin_setjmp/__builtin_longjmp buffer layout is suggested in case of cet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94218 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > "This can make __builtin_setjmp and __builtin_longjmp more efficient than > their library counterparts in some cases, but it can also cause incorrect > and mysterious behavior when mixing with code that uses the full register > set." CET is considered register set differences.
[Bug target/94218] Different __builtin_setjmp/__builtin_longjmp buffer layout is suggested in case of cet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94218 --- Comment #6 from Andrew Pinski --- Also: "GCC provides the built-in functions __builtin_setjmp and __builtin_longjmp which are similar to, but not interchangeable with, the C library functions setjmp and longjmp."
[Bug target/94218] Different __builtin_setjmp/__builtin_longjmp buffer layout is suggested in case of cet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94218 --- Comment #8 from Andrew Pinski --- (In reply to gsdrtge6h from comment #7) > Okay, but why the current layout is any better than the suggested layout. Because these are not useful for anything really. The suggested layout might require big changes in the compiler which does not make a big difference in the long run anways since these are not used except for testing to make sure sjlj eh still works.
[Bug c/94222] Architecture dependent problem with vsnprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94222 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- You need to use va_copy or va_start and va_end again for the second vsnprintf.
[Bug c/94222] Architecture dependent problem with vsnprintf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94222 --- Comment #3 from Andrew Pinski --- (In reply to Jaroslav Fojtík from comment #2) > Sorry, it worked for many years without any problems. I has been fixed a > problem in my WP2LaTeX now. Well it depends on the ABI for va_list . On the targets where it works, it is just a pointer which is passed via value and does not get changed by the first vnsprintf. On targets where it does not work, va_list is an array of size 1 of a struct; there for is passed via reference really and gets changed by the first vnsprintf. That is why it was working before hand but only on accident. There are many documentation about this issue for the last 20 years really since va_copy was added in C99. https://www.gnu.org/software/libc/manual/html_node/Argument-Macros.html
[Bug fortran/94228] Preprocessor inconsistency for macros when invoked from gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94228 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- gfortran defaults to -traditional-cpp preprocessor mode.
[Bug target/94236] -mcmodel=large does not work on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94236 --- Comment #1 from Andrew Pinski --- -mcmodel=large does not control long calls.
[Bug target/94236] -mcmodel=large does not work on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94236 --- Comment #2 from Andrew Pinski --- A patch for -mlong-calls was posted a long time ago but never made it in: https://gcc.gnu.org/legacy-ml/gcc-patches/2014-10/msg02933.html You should not need -mlong-calls really because the linker should insert stubs to do the long calls in the end. Why do you think you need full 64bit addressing for calls rather than the stubs?
[Bug target/94236] -mcmodel=large does not work on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94236 --- Comment #4 from Andrew Pinski --- Do you have a source where you run into a relocation overflowing? Or is there a specific reason why you need long calls here?
[Bug libstdc++/94241] ranges::find_if doesn't like data structures defined in a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94241
--- Comment #2 from Andrew Pinski ---
#include
int main()
{
struct s { int m; };
s r[] = { s{0}, s{1}, s{2}, s{3} };
std::ranges::find_if(r, [](auto const) { return true; });
}
[Bug c++/94241] ranges::find_if doesn't like data structures defined in a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94241 Andrew Pinski changed: What|Removed |Added Keywords||rejects-valid Component|libstdc++ |c++ --- Comment #3 from Andrew Pinski --- This looks like a front-end issue rather than a library issue.
[Bug libstdc++/553] Call to sort () results in segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=553 Andrew Pinski changed: What|Removed |Added CC||markd at kermodei dot com --- Comment #8 from Andrew Pinski --- *** Bug 94244 has been marked as a duplicate of this bug. ***
[Bug libstdc++/94244] std::sort corrupts memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94244 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- your compare has an ordering issue. That is a.tStart <= b.tStart will cause to return true when a and b point to the same element. See PR 553. *** This bug has been marked as a duplicate of bug 553 ***
[Bug c/94247] Wrong char-subscripts warning for limited-range index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94247 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Andrew Pinski --- The warning is not context sensitive. What I mean is it does not take into account the range of k. Also you can avoid the warning by using either unsigned char or signed char. char is a special type. Unlike other plain types, it can default either to signed or unsigned and for GCC it depends on the ABI. >and the compiler already knows this Not when the warning is generated from the front-end. It does not know the range of the char variable there.
[Bug rtl-optimization/94256] Setting max-sched-region-blocks to >48 causes GCC memory usage to explode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94256
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WONTFIX
--- Comment #1 from Andrew Pinski ---
That is why it is limited in the first place:
/* Update number of blocks and the estimate for number of insns
in the region. Return true if the region is "too large" for interblock
scheduling (compile time considerations). */
static bool
too_large (int block, int *num_bbs, int *num_insns)
{
(*num_bbs)++;
(*num_insns) += (common_sched_info->estimate_number_of_insns
(BASIC_BLOCK_FOR_FN (cfun, block)));
return ((*num_bbs > param_max_sched_region_blocks)
|| (*num_insns > param_max_sched_region_insns));
}
CUT -
having a more than 10 basic blocks in a region is huge really.
[Bug c/94258] Warning Correction while using format specifiers %hx and %ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94258 --- Comment #1 from Andrew Pinski --- Short types are promoted to int when passed to variable arguments functions.
[Bug c/94258] Warning Correction while using format specifiers %hx and %ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94258
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Andrew Pinski ---
t444.c: In function ‘main’:
t444.c:4:12: warning: format ‘%ho’ expects argument of type ‘int’, but argument
2 has type ‘double’ [-Wformat=]
4 | printf("%ho\n", 0.0);
| ~~^ ~~~
|| |
|int double
| %f
t444.c:5:12: warning: format ‘%hx’ expects argument of type ‘int’, but argument
2 has type ‘double’ [-Wformat=]
5 | printf("%hx\n", 0.0);
| ~~^ ~~~
|| |
|int double
| %f
That is correct warning as I mentioned. There is no short when passed via
variable arugments.
[Bug target/94236] -mcmodel=large does not work on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94236 --- Comment #6 from Andrew Pinski --- Note for Threos OS, please don't reuse the same target triplet as elf or linux; use your own triplet. Also adding long calls is not hard and such.
[Bug c/94247] Wrong char-subscripts warning for limited-range index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94247 --- Comment #8 from Andrew Pinski --- (In reply to Martin Sebor from comment #7) > (In reply to Jakub Jelinek from comment #6) > > No, it diagnoses the main bug > > Nope, it does not. -Wchar-subscripts is designed and documented to diagnose > a common cause of a bug. The actual bug itself (which, as noted in pr94182, > the manual neglects to describe) is in inadvertently using a negative index > as a result of sign extension when a positive index is intended. When that > cannot happen there is obviously no bug to diagnose. Yes and no. Let's look at it a different way. negative index is not the issue. But rather knowing if char is signed or unsigned is the issue. it is a portability issue. -Wchar-subscripts is designed to diagnostic that you use char in a subscript as you might not know if it is signed or unsigned because the ABI differences. Look at PowerPC or ARM ABIs, you will notice that char is unsigned while other ABIs, char is signed. YES with the code in comment #0, there would be no difference but having a false negative is fine. Not all warnings are going to be 100% because of the heurstics. Since the false negative is easy workarounded, just use signed char or unsigned char or int as the loop variable. char is a special type as I keep on mentioning.
[Bug tree-optimization/94293] [missed optimization] Useless statements populating local string not removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94293 --- Comment #8 from Andrew Pinski --- (In reply to Eyal Rozenberg from comment #6) > (In reply to Richard Biener from comment #5) > > DSE part ... DCE > > DSE = Dead Statement Elimination? DCE = Dead Code Elimination? I thought Dse was dead store elimination.
[Bug sanitizer/94299] false positive: AddressSanitizer: stack-use-after-scope on address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94299 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2020-03-24 --- Comment #1 from Andrew Pinski --- >I believe it is a false positive. If it is a false positive, then without address santiizer, GCC might produce wrong code But I really have my doubts. What line is causing the failure? That is what does: #1 0x7fffdb147b04 in lldb_private::CommandObject::CommandObject(lldb_private::CommandInterpreter&, llvm::StringRef, llvm::StringRef, llvm::StringRef, unsigned int) (/quad/home/jkratoch/redhat/llvm-monorepo3-gccassertdebugasanO1/bin/../lib/liblldb.so.11git+0x3dd5b04) Correspond to?
[Bug sanitizer/94299] false positive: AddressSanitizer: stack-use-after-scope on address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94299 --- Comment #2 from Andrew Pinski --- I forgot to say one more thing, GCC is more strict than LLVM when it comes to temps going out of scope too.
[Bug sanitizer/94299] false positive: AddressSanitizer: stack-use-after-scope on address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94299
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|--- |INVALID
--- Comment #6 from Andrew Pinski ---
GCC is correct:
llvm::StringRef GetHelp() { return (m_help.empty() ? "" : m_help); }
has a std::string temp for "" because the conversion to std::string in the ?:.
And then StringRef::StringRef does:
/// Construct a string ref from an std::string.
/*implicit*/ StringRef(const std::string &Str)
: Data(Str.data()), Length(Str.length()) {}
So GCC is correct.
