[Bug tree-optimization/90387] [9/10 Regression] __builtin_constant_p and -Warray-bounds warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90387 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #7 from Richard Biener --- Testing that patch.
[Bug other/91730] [10 regression] r275518 causes 3 verification errors in the cpu 2006 test suite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91730 Richard Biener changed: What|Removed |Added Target|powerpc64le-unknown-linux-g |powerpc64le-unknown-linux-g |nu |nu, x86_64-*-* CC||barnaby.wilks at arm dot com Blocks||26163 Target Milestone|--- |10.0 --- Comment #1 from Richard Biener --- Using -Ofast I presume? Note there's the 'match' debug-counter you can use to bisect the offending transform (per source file of course). Confirmed on a Haswell machine with -Ofast -march=native as well. Not exactly wrong-code confirmed yet but we'd like to have SPEC CPU "-Ofast clean" and thus need to understand what actual transform is bad here. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug rtl-optimization/89795] [7/8/9/10 Regression] wrong code with -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89795 Eric Botcazou changed: What|Removed |Added Component|target |rtl-optimization --- Comment #9 from Eric Botcazou --- Recategorizing.
[Bug other/91730] [10 regression] r275518 causes 3 verification errors in the cpu 2006 test suite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91730 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-11 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- I can confirm that and I'm going to bisect the transformation.
[Bug middle-end/91709] Missed optimization for multiplication on 1.5 and 1.25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91709 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-11 Ever confirmed|0 |1 --- Comment #5 from Richard Biener --- Confirmed with an appropriate subset of -ffast-math flags.
[Bug other/91730] [10 regression] r275518 causes 3 verification errors in the cpu 2006 test suite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91730 --- Comment #4 from Martin Liška --- Created attachment 46869 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46869&action=edit Dump file without problematic transformation
[Bug other/91730] [10 regression] r275518 causes 3 verification errors in the cpu 2006 test suite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91730 --- Comment #3 from Martin Liška --- Created attachment 46868 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46868&action=edit Dump file with problematic transformation For the 453.povray (which fails with --size=test), the problematic file is: g++ -c -o quadrics.o -dspec_cpu -dndebug -ofast -g -fpermissive -dspec_cpu_lp64 quadrics.cpp -fdbg-cnt=match:4030 Where match:4030 is the first bad debug counter value.
[Bug tree-optimization/90387] [9/10 Regression] __builtin_constant_p and -Warray-bounds warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90387 --- Comment #8 from Marc Glisse --- (In reply to Bernd Buschinski from comment #6) > From the comments I assumed that the fix is kind of trivial There is a simple change that gives the behavior you want on one example, but it is far from trivial whether that is generally a good idea. Giving up on __builtin_constant_p earlier (there are quite a few passes between vrp1 and dom2) means that there are cases where we will say 'false' while we were able to say 'true' before, which is a missed optimization. On the other hand, the more complicated CFG created by _bcp may hinder some other optimizations, so it may also help. The question is how often that will happen and how important those cases are. Honestly, false positives with Warray-bounds are a secondary concern, you can just disable the warning, like Wmaybe-uninitialized and a few others that are meant to have false positives.
[Bug other/91730] [10 regression] r275518 causes 3 verification errors in the cpu 2006 test suite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91730 --- Comment #5 from Martin Liška --- The transformation is from: _663 = T1$1_55 + _293; _651 = (float) _663; where T1$1_55 and _293 are doubles. To: _758 = (float) T1$1_55; _759 = (float) _293; _760 = _758 + _759; _651 = (float) _760;
[Bug fortran/91716] [9/10 Regression] ICE in output_constant, at varasm.c:5026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91716
Richard Biener changed:
What|Removed |Added
Keywords||ice-checking
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-09-11
CC||edlinger at gcc dot gnu.org,
||law at gcc dot gnu.org
Target Milestone|--- |9.3
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
#1 0x0174739f in output_constant (exp=,
size=1, align=8, reverse=false, merge_strings=false)
at /space/rguenther/src/svn/trunk2/gcc/varasm.c:5026
5026 gcc_checking_assert (check_string_literal (exp, size));
Confirmed.
4834static bool
4835check_string_literal (tree string, unsigned HOST_WIDE_INT size)
4836{
...
4849 if (mem_size != size)
4850return false;
triggers. mem_size == 0, size == 1.
but thissize in the caller is 0, still we pass in 'size'!?
blaming the above shows Jeff and Bernd (CCed).
[Bug c++/91718] [9/10 Regression] Inherited constructors with arrays of objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91718 Richard Biener changed: What|Removed |Added Keywords||accepts-invalid Known to work||9.2.0 Target Milestone|--- |9.3 Summary|Inherited constructors with |[9/10 Regression] Inherited |arrays of objects |constructors with arrays of ||objects
[Bug other/91730] [10 regression] r275518 causes 3 verification errors in the cpu 2006 test suite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91730 --- Comment #6 from Richard Biener --- (In reply to Martin Liška from comment #5) > The transformation is from: > > _663 = T1$1_55 + _293; > _651 = (float) _663; > > where T1$1_55 and _293 are doubles. To: > > _758 = (float) T1$1_55; > _759 = (float) _293; > _760 = _758 + _759; > _651 = (float) _760; OK, so thats invalid for example when T1$1_55 and _293 are FP values that cannot be represented in 'float' but their sum can. That's outside of what we generally allow with -ffast-math. It would be valid if one of T1$1_55 or _293 are already float.
[Bug other/91730] [10 regression] r275518 causes 3 verification errors in the cpu 2006 test suite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91730 --- Comment #7 from Richard Biener --- Note in all cases of the testcases coming with the patch the sources are eventually casted from float to double.
[Bug other/91730] [10 regression] r275518 causes 3 verification errors in the cpu 2006 test suite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91730 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Reverted the patch.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 91730, which changed state. Bug 91730 Summary: [10 regression] r275518 causes 3 verification errors in the cpu 2006 test suite https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91730 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/90387] [9/10 Regression] __builtin_constant_p and -Warray-bounds warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90387 --- Comment #9 from Richard Biener --- So it's the following passes (if you ignore that with -fopenacc we already fold b_c_p during early opts): NEXT_PASS (pass_vrp, true /* warn_array_bounds_p */); NEXT_PASS (pass_dce); NEXT_PASS (pass_stdarg); NEXT_PASS (pass_call_cdce); NEXT_PASS (pass_cselim); NEXT_PASS (pass_copy_prop); NEXT_PASS (pass_tree_ifcombine); NEXT_PASS (pass_merge_phi); NEXT_PASS (pass_phiopt, false /* early_p */); NEXT_PASS (pass_tail_recursion); NEXT_PASS (pass_ch); NEXT_PASS (pass_lower_complex); NEXT_PASS (pass_sra); /* The dom pass will also resolve all __builtin_constant_p calls that are still there to 0. This has to be done after some propagations have already run, but before some more dead code is removed, and this place fits nicely. Remember this when trying to move or duplicate pass_dominator somewhere earlier. */ NEXT_PASS (pass_thread_jumps); NEXT_PASS (pass_dominator, true /* may_peel_loop_headers_p */); There's constant propagation, value-numbering and complete loop unrolling after inlining and before the above VRP pass plus one backwards jump threading pass. Note DOM applies the folding before jump threading. I'd argue none of the above besides maybe loop-header copying should expose more opportunities to fold b_c_p to true. If SRA would do then I'd call it a missed value-numbering opportunity (not to say it's impossible). So the risks of pessimization are IMHO low. So if testing doesn't reveal anything I'm going to do this change on trunk at least.
[Bug middle-end/91725] [10 Regression] ICE in get_nonzero_bits starting with r275587
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91725 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Wed Sep 11 08:33:55 2019 New Revision: 275633 URL: https://gcc.gnu.org/viewcvs?rev=275633&root=gcc&view=rev Log: PR middle-end/91725 * match.pd ((A / (1 << B)) -> (A >> B)): Call tree_nonzero_bits instead of get_nonzero_bits, only call it for integral types. * gcc.c-torture/compile/pr91725.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr91725.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/91723] [9/10 Regression] builtin fma is not optimized or vectorized as *+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91723 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Wed Sep 11 08:34:41 2019 New Revision: 275634 URL: https://gcc.gnu.org/viewcvs?rev=275634&root=gcc&view=rev Log: PR tree-optimization/91723 * tree-vect-stmts.c (vectorizable_call): Use types_compatible_p check instead of pointer equality when checking if argument vectypes are the same. * gcc.dg/vect/vect-fma-3.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/vect-fma-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/91723] [9 Regression] builtin fma is not optimized or vectorized as *+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91723 Jakub Jelinek changed: What|Removed |Added Summary|[9/10 Regression] builtin |[9 Regression] builtin fma |fma is not optimized or |is not optimized or |vectorized as *+|vectorized as *+ --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/91725] [10 Regression] ICE in get_nonzero_bits starting with r275587
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91725 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug target/91720] [10 Regression] wrong code with -Og -fno-forward-propagate -frerun-cse-after-loop -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91720 --- Comment #10 from Jakub Jelinek --- (In reply to Eric Botcazou from comment #9) > > That change added the && !REG_P in there, but unless the reg is loaded from > > memory, it is unclear how it can guarantee that the upper bits are zero > > (resp. sign) extended after arbitrary operations. > > Precisely because WORD_REGISTER_OPERATIONS is defined, i.e. the processor is > supposed to operate only a full registers. True, but that still doesn't imply that the upper bits are zeros. If something is loaded from memory, we do get that guarantee. But if we do say PLUS, the lowest upper bit might be 0 or 1, the bits above it zeros. If a constant is loaded into a register, the upper bits might be all zeros or all ones. For a multiplication, the upper bits could be anything, etc. > But, OK, I'm going to remove the > problematic && !REG_P and XFAIL the associated testcase. Does that also fix PR89795?
[Bug target/91719] gcc compiles seq_cst store on x86-64 differently from clang/icc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91719 --- Comment #9 from vekumar at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #8) > CCing AMD too. Sure Let me check if this tuning helps AMD Zen Arch.
[Bug tree-optimization/91734] New: gcc skip an if statement with "-O1 -ffast-math"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734
Bug ID: 91734
Summary: gcc skip an if statement with "-O1 -ffast-math"
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: chinoune.mehdi at hotmail dot com
Target Milestone: ---
Building this program with gcc [8,9] "-O1 -ffast-math" makes the result
overflows.
#include
#include
#include
#include
void foo(float complex z, float *y){
float const sqrt_flt_min = sqrtf( FLT_MIN );
float az;
az = cabsf(z);
//az = cabsf(z/sqrt_flt_min) * sqrt_flt_min;
if( az [local count: 1073741824]:
cabs_17 = REALPART_EXPR ;
cabs_18 = cabs_17 * cabs_17;
cabs_19 = IMAGPART_EXPR ;
cabs_20 = cabs_19 * cabs_19;
cabs_21 = cabs_18 + cabs_20;
powroot_22 = __builtin_sqrtf (cabs_21);
_3 = (double) powroot_22;
__printf_chk (1, "az = %.8e\n", _3);
_4 = 1.0e+0 / powroot_22;
*y_10(D) = _4;
return;
}
;; Function main (main, funcdef_no=33, decl_uid=4154, cgraph_uid=34,
symbol_order=33) (executed once)
main ()
{
float y;
float y.0_1;
double _2;
[local count: 1073741824]:
foo (__complex__
(9.996826552253889678874634872052240552875446155667305e-20, 0.0), &y);
y.0_1 = y;
_2 = (double) y.0_1;
__printf_chk (1, "y = %.7e\n", _2);
y ={v} {CLOBBER};
return 0;
}
There is no if statement!
[Bug target/91720] [10 Regression] wrong code with -Og -fno-forward-propagate -frerun-cse-after-loop -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91720 --- Comment #11 from Eric Botcazou --- > Does that also fix PR89795? Yes, I'm going to fix PR89795 and let you check what happens for this one.
[Bug target/91735] New: Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 Bug ID: 91735 Summary: Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com Target Milestone: --- The SUSE SPECfp2000 continuous regression tester shows a ~20% runtime regression on Haswell around the end of August 2018. [1] https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64/
[Bug rtl-optimization/91721] Missed optimization for checking nan and comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91721 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-11 Component|target |rtl-optimization Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Probably something for generic RTL opts unless UNSPECs are involved here.
[Bug target/91722] gcc generates sub-optimal assembly when AVX instructions are used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91722 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-11 Known to work||10.0 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed. Doesn't seem to be a regression, so up to target maintainers to close as fixed.
[Bug fortran/91731] Configure error on building MPICH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91731 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Thomas Koenig --- See PR 91556. In the meantime, use -fallow-argument-mismatch . I am working on a better error message. *** This bug has been marked as a duplicate of bug 91556 ***
[Bug fortran/91556] Problems with better interface checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556 Thomas Koenig changed: What|Removed |Added CC||damian at sourceryinstitute dot or ||g --- Comment #27 from Thomas Koenig --- *** Bug 91731 has been marked as a duplicate of this bug. ***
[Bug lto/91724] [8 Regression] profiled lto bootstrap fails on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91724 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |8.4 --- Comment #1 from Richard Biener --- Hmm, can you bisect this a bit? It may be a latent issue is uncovered. Disabling compare-debug might also help getting better backtraces. Looks like loop-invariant has inconsistent DF state somehow. In the ../../src/gcc/df-core.c:1594 frame it is interesting to know the problem causing this. Maybe the backtrace is also completely bogus since there shoud be no hash-tables involved here... P1 until we know some more.
[Bug fortran/91729] [10 Regression] ICE in gfc_match_select_rank, at fortran/match.c:6586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91729 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |10.0
[Bug fortran/91726] [8/9/10 Regression] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91726 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |8.4
[Bug tree-optimization/91732] Adding omp simd pragma prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91732
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization, openmp
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-09-11
CC||jakub at gcc dot gnu.org
Component|c |tree-optimization
Blocks||53947
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
The runtime alias test is between the two stores of the inner unrolled loop.
That's dv[i] vs. dv[i+Q].
Creating dr for *_61
analyze_innermost: success.
base_address: dv_44(D)
offset from base address: 0
constant offset from base address: 0
step: 8
base alignment: 8
base misalignment: 0
offset alignment: 512
step alignment: 8
base_object: *dv_44(D)
Access function 0: {0B, +, 8}_1
Creating dr for *_79
analyze_innermost: success.
base_address: (double *) dv_44(D) + (sizetype) ((long unsigned int)
Q_35(D) * 8)
offset from base address: 0
constant offset from base address: 0
step: 8
base alignment: 8
base misalignment: 0
offset alignment: 512
step alignment: 8
base_object: *(double *) dv_44(D) + (sizetype) ((long unsigned int)
Q_35(D) * 8)
Access function 0: {0B, +, 8}_1
it's probably unfortunate association since we compute inside the loop
_11 = Q_35(D) + i_39;
_12 = (long unsigned int) _11;
_13 = _12 * 8;
With OpenMP SIMD we fail to analyze the data-refs:
Creating dr for D.4113[_37][1][0]
analyze_innermost: t.c:4:18: missed: failed: evolution of offset is not
affine.
base_address:
offset from base address:
constant offset from base address:
step:
base alignment: 0
base misalignment: 0
offset alignment: 0
step alignment: 0
base_object: D.4113
Access function 0: 0
Access function 1: 1
Access function 2: scev_not_known;
where _37 is the SIMD lane.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/91732] Adding omp simd pragma prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91732 Jakub Jelinek changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- The routine is obfuscated too much, why not use gsym[Q*2*j+i] instead of g[j][0] and similarly gsym[Q*2-j*Q+i] instead of g[j][1]? The reason this isn't vectorized is that we need to effectively privatize the g variable, because every SIMD lane needs different values for it, and SRA isn't able to split that appart into scalars indexed by the simd lane. So, in the end this is pretty much a dup of PR91020.
[Bug tree-optimization/91734] gcc skip an if statement with "-O1 -ffast-math"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734 --- Comment #1 from Andrew Pinski --- So two things: -funsafe-math-optimizations assumes there are no denormals (subnormals) or they are flushed to zero. -ffinite-math-only assumes that infinite and nans don't exists (IIRC).
[Bug c++/90767] [9/10 Regression] jumbled error message with this and const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90767
Bartosz Szreder changed:
What|Removed |Added
CC||bartosz.szreder@huuugegames
||.com
--- Comment #4 from Bartosz Szreder ---
Another testcase, slightly different error message. Making A::f() a
non-template member function gives sensible results.
struct A {
struct B
{
B(int) {}
};
template void f()
{
int x = 0;
g(x);
}
void g(B& arg) {}
};
$ g++ test.cpp
test.cpp: In member function ‘void A::f()’:
test.cpp:10:11: error: cannot convert ‘#‘view_convert_expr’ not supported by
dump_type#’ to ‘A::B&’
10 | g(x);
| ^
| |
| #‘view_convert_expr’ not supported by dump_type#
test.cpp:13:16: note: initializing argument 1 of ‘void A::g(A::B&)’
13 | void g( B& arg ) {}
|
[Bug target/91736] New: Runtime regression for SPEC2000 252.eon on Haswell around beginning of February 2019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91736 Bug ID: 91736 Summary: Runtime regression for SPEC2000 252.eon on Haswell around beginning of February 2019 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com Target Milestone: --- The SUSE SPECint2000 continuous regression tester shows a ~8% runtime regression on Haswell around the beginning of February 2019. [1] https://gcc.opensuse.org/gcc-old/SPEC/CINT/sb-czerny-head-64/252_eon_big.png
[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |NEW Known to work||8.3.1 Version|unknown |9.1.0 Keywords||missed-optimization Last reconfirmed||2019-09-11 CC||rguenth at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Blocks||53947, 26163 Ever confirmed|0 |1 Summary|Runtime regression for |[9/10 Regression] Runtime |SPEC2000 177.mesa on|regression for SPEC2000 |Haswell around the end of |177.mesa on Haswell around |August 2018 |the end of August 2018 Target Milestone|--- |9.3 --- Comment #1 from Richard Biener --- From the testers data last good r263752, first bad r263787. Bisecting points to Richards vectorizer series r26377[1-4], more specifically r263772. Perf shows nothing conclusive but all functions slower by the same percentage. SPEC 2000 build scripts are oddly redirecting and mangling output so -fopt-info output is illegible. Huh, or rather it's even in the dumps when dumping with -optimized: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: polygon.c:140:4: note: loop vectorized using 32 byte vectors anyhow, differences are for example: fog.c:157:10: note: loop vectorized using 32 byte vectors +fog.c:157:10: note: fog.c:157:10: note: loop versioned for vectorization because of possible aliasing the above is void gl_fog_color_vertices( GLcontext *ctx, GLuint n, GLfloat v[][4], GLubyte color[][4] ) ... case GL_EXP: d = -ctx->Fog.Density; for (i=0;ihttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 --- Comment #2 from Richard Biener --- Errr, before we _dont_ vectorize.
[Bug libgcc/91737] New: On Alpine Linux (libmusl) a statically linked C++ program which throws the first exception in two threads at the same time can busy spin on shutdown after main().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91737 Bug ID: 91737 Summary: On Alpine Linux (libmusl) a statically linked C++ program which throws the first exception in two threads at the same time can busy spin on shutdown after main(). Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: max at arangodb dot com Target Milestone: --- Created attachment 46870 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46870&action=edit Program exposing the problem when compiled under Alpine Linux and linked statically. My statically linked program runs a busy loop after main() has terminated, provided that the very first exception that is thrown in the run is thrown in two threads at the very same time. The attached program shows the problem. This only happens on Linux, and only if one does not use glibc as C-library, and only if the executable is statically linked and does not explicitly use the `pthread_cancel` function. I tested with g++ 8.3.0, but I think the problem is present in other versions as well. Here is what is happening: In the file `libgcc/unwind-dw2-fde.c` in the function `_Unwind_Find_FDE` there is a mutex which is only acquired if the underlying program is detected to be "multi-threaded". This test for multi-threadedness is done differently on various platforms (see file `libgcc/gthr-posix.h` lines 156 to 306). On Linux without glibc and if it is not the Android bionic C library, a weak reference to the symbol `pthread_cancel` is used. If the underlying program does not explicitly use `pthread_cancel` (and few C++ programs will, because cancelling threads is not in the C++ standard), and the linking is done statically, the program will link `libpthread` but not have a symbol `pthread_cancel`. In this case the mutex is not used at all. If now the first exception in the program happens in two exceptions concurrently, the function `_Unwind_Find_FDE` will move an object from the static list `unseen_objects` to the static list `seen_objects` and a data race occurs. Sometimes, the same object is moved twice from one list to the other. This leads to the fact that the `seen_objects` list ends in an object which points to itself (with the `next` pointer). In this case, on shutdown, well after main() and all static destructors, the function `__deregister_frame_info_bases` will busy loop running around the circular data structure `seen_objects`. I think this is overoptimized and the multi-threadedness detection does not work for many statically linked programs when libmusl is used as underlying C-library.
[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 --- Comment #3 from Richard Biener --- Reducing the VF here should be the goal. For the particular case "filling" the holes with neutral data and blending in the original values at store time will likely be optimal. So do tem = vector load zero all [4] elements compute blend in 'tem' into the [4] elements vector store eliding all the shuffling/striding. Should end up at a VF of 4 (SSE) or 8 (AVX). Doesn't fit very well into the current vectorizer architecture. So currently we can only address this from the costing side. arm can probably leverage load/store-lanes here. With char elements and an SLP size of 3 it's probably the worst case we can think of.
[Bug rtl-optimization/89795] [7/8/9/10 Regression] wrong code with -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89795 --- Comment #10 from Eric Botcazou --- Author: ebotcazou Date: Wed Sep 11 10:41:27 2019 New Revision: 275635 URL: https://gcc.gnu.org/viewcvs?rev=275635&root=gcc&view=rev Log: PR rtl-optimization/89795 * rtlanal.c (nonzero_bits1) : Do not propagate results from inner REGs to paradoxical SUBREGs if WORD_REGISTER_OPERATIONS is set. Modified: trunk/gcc/ChangeLog trunk/gcc/rtlanal.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/sparc/2016-1.c
[Bug rtl-optimization/89795] [7/8/9/10 Regression] wrong code with -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89795 --- Comment #11 from Eric Botcazou --- Author: ebotcazou Date: Wed Sep 11 10:42:31 2019 New Revision: 275636 URL: https://gcc.gnu.org/viewcvs?rev=275636&root=gcc&view=rev Log: PR rtl-optimization/89795 * rtlanal.c (nonzero_bits1) : Do not propagate results from inner REGs to paradoxical SUBREGs if WORD_REGISTER_OPERATIONS is set. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/rtlanal.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gcc.target/sparc/2016-1.c
[Bug rtl-optimization/89795] [7/8/9/10 Regression] wrong code with -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89795 --- Comment #12 from Eric Botcazou --- Author: ebotcazou Date: Wed Sep 11 10:43:19 2019 New Revision: 275637 URL: https://gcc.gnu.org/viewcvs?rev=275637&root=gcc&view=rev Log: PR rtl-optimization/89795 * rtlanal.c (nonzero_bits1) : Do not propagate results from inner REGs to paradoxical SUBREGs if WORD_REGISTER_OPERATIONS is set. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/rtlanal.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.target/sparc/2016-1.c
[Bug rtl-optimization/89795] [7/8/9/10 Regression] wrong code with -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89795 --- Comment #13 from Eric Botcazou --- Author: ebotcazou Date: Wed Sep 11 10:44:06 2019 New Revision: 275638 URL: https://gcc.gnu.org/viewcvs?rev=275638&root=gcc&view=rev Log: PR rtl-optimization/89795 * rtlanal.c (nonzero_bits1) : Do not propagate results from inner REGs to paradoxical SUBREGs if WORD_REGISTER_OPERATIONS is set. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/rtlanal.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gcc.target/sparc/2016-1.c
[Bug rtl-optimization/89795] [7/8/9/10 Regression] wrong code with -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89795 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Eric Botcazou --- Fixed on all branches.
[Bug target/91736] Runtime regression for SPEC2000 252.eon on Haswell around beginning of February 2019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91736 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-11 Version|unknown |9.1.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Last known good r268430, first known bad r268456. Note it's a regression during GCC 9 development so compared to GCC 8 it's not a regression.
[Bug tree-optimization/91734] gcc skip an if statement with "-O1 -ffast-math"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734 --- Comment #2 from Chinoune --- Replacing `if( az
[Bug tree-optimization/90387] [9/10 Regression] __builtin_constant_p and -Warray-bounds warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90387 --- Comment #10 from Richard Biener --- Author: rguenth Date: Wed Sep 11 11:16:54 2019 New Revision: 275639 URL: https://gcc.gnu.org/viewcvs?rev=275639&root=gcc&view=rev Log: 2019-09-11 Richard Biener PR tree-optimization/90387 * vr-values.c (vr_values::extract_range_basic): After inlining simplify non-constant __builtin_constant_p to false. * gcc.dg/Warray-bounds-44.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-44.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/vr-values.c
[Bug tree-optimization/90387] [9 Regression] __builtin_constant_p and -Warray-bounds warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90387 Richard Biener changed: What|Removed |Added Known to work||10.0 Summary|[9/10 Regression] |[9 Regression] |__builtin_constant_p and|__builtin_constant_p and |-Warray-bounds warnings |-Warray-bounds warnings Known to fail|10.0| --- Comment #11 from Richard Biener --- Fixed on trunk sofar, not sure if backporting.
[Bug rtl-optimization/89795] [7/8/9/10 Regression] wrong code with -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89795 --- Comment #15 from Jakub Jelinek --- Author: jakub Date: Wed Sep 11 11:37:39 2019 New Revision: 275642 URL: https://gcc.gnu.org/viewcvs?rev=275642&root=gcc&view=rev Log: PR rtl-optimization/89435 PR rtl-optimization/89795 PR rtl-optimization/91720 * gcc.dg/pr89435.c: New test. * gcc.dg/pr89795.c: New test. * gcc.dg/pr91720.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr89435.c trunk/gcc/testsuite/gcc.dg/pr89795.c trunk/gcc/testsuite/gcc.dg/pr91720.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/91720] [10 Regression] wrong code with -Og -fno-forward-propagate -frerun-cse-after-loop -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91720 --- Comment #12 from Jakub Jelinek --- Author: jakub Date: Wed Sep 11 11:37:39 2019 New Revision: 275642 URL: https://gcc.gnu.org/viewcvs?rev=275642&root=gcc&view=rev Log: PR rtl-optimization/89435 PR rtl-optimization/89795 PR rtl-optimization/91720 * gcc.dg/pr89435.c: New test. * gcc.dg/pr89795.c: New test. * gcc.dg/pr91720.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr89435.c trunk/gcc/testsuite/gcc.dg/pr89795.c trunk/gcc/testsuite/gcc.dg/pr91720.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/89435] [7/8/9 Regression] wrong code with -O1 -march=armv4 -fno-forward-propagate with __builtin_sub_overflow()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89435 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Wed Sep 11 11:37:39 2019 New Revision: 275642 URL: https://gcc.gnu.org/viewcvs?rev=275642&root=gcc&view=rev Log: PR rtl-optimization/89435 PR rtl-optimization/89795 PR rtl-optimization/91720 * gcc.dg/pr89435.c: New test. * gcc.dg/pr89795.c: New test. * gcc.dg/pr91720.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr89435.c trunk/gcc/testsuite/gcc.dg/pr89795.c trunk/gcc/testsuite/gcc.dg/pr91720.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/91720] [10 Regression] wrong code with -Og -fno-forward-propagate -frerun-cse-after-loop -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91720 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #13 from Jakub Jelinek --- Fixed by the PR89795 fix. *** This bug has been marked as a duplicate of bug 89795 ***
[Bug rtl-optimization/89795] [7/8/9/10 Regression] wrong code with -O2 -fno-dce -fno-forward-propagate -fno-sched-pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89795 --- Comment #16 from Jakub Jelinek --- *** Bug 91720 has been marked as a duplicate of this bug. ***
[Bug debug/82738] [meta-bug] issues with the -Og optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82738 Bug 82738 depends on bug 91720, which changed state. Bug 91720 Summary: [10 Regression] wrong code with -Og -fno-forward-propagate -frerun-cse-after-loop -fno-tree-fre https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91720 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug target/91736] Runtime regression for SPEC2000 252.eon on Haswell around beginning of February 2019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91736 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Blocks||26163 --- Comment #2 from Richard Biener --- As expected it regressed with r268448 which dropped max-inline-insns-single from 400 to 200. Honza should remember what was importrant to optimize here (but certainly SPEC 2000 ceased to be relevant). 5.93% 9002 eon_base.none eon_base.none [.] mrGrid::viewingHit 5.57% 8478 eon_base.none eon_base.none [.] mrSurfaceList::viewingHit 5.50% 8296 eon_peak.none eon_peak.none [.] mrSurfaceList::viewingHit 5.17% 7789 eon_peak.none eon_peak.none [.] ggGridIterator::ggGridIterato 4.34% 6533 eon_peak.none eon_peak.none [.] mrGrid::viewingHit 4.18% 6332 eon_base.none eon_base.none [.] mrGrid::shadowHit 3.26% 4908 eon_peak.none eon_peak.none [.] mrGrid::shadowHit suggests that inlining ggGridIterator is important and missing now, likely into viewingHit. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- The endless series of vpextrb look terrible, can't that be handled by possibly masked permutation?
[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 --- Comment #5 from Uroš Bizjak --- (In reply to Richard Biener from comment #3) > Reducing the VF here should be the goal. For the particular case "filling" > the holes with neutral data and blending in the original values at store time > will likely be optimal. So do > > tem = vector load > zero all [4] elements > compute > blend in 'tem' into the [4] elements > vector store MASKMOVDQU [1] should be an excellent fit here. [1] https://www.felixcloutier.com/x86/maskmovdqu
[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 --- Comment #6 from rguenther at suse dot de --- On Wed, 11 Sep 2019, ubizjak at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 > > --- Comment #5 from Uroš Bizjak --- > (In reply to Richard Biener from comment #3) > > Reducing the VF here should be the goal. For the particular case "filling" > > the holes with neutral data and blending in the original values at store > > time > > will likely be optimal. So do > > > > tem = vector load > > zero all [4] elements > > compute > > blend in 'tem' into the [4] elements > > vector store > > MASKMOVDQU [1] should be an excellent fit here. Yes, but it's probably slower. And it avoids store data races, of course plus avoids epilogue peeling (eventually).
[Bug tree-optimization/91732] Adding omp simd pragma prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91732 --- Comment #3 from Jed Brown --- > why not use gsym[Q*2*j+i] instead of g[j][0] and similarly gsym[Q*2-j*Q+i] > instead of g[j][1]? The pattern here is that gsym is packed storage of a symmetric 2x2 matrix, while g unpacks it so that inner loops (intended for unrolling) can be written using index notation. This case (a finite element quadrature routine for 2D anisotropic Poisson) is reduced from more complicated examples (such as 3D nonlinear solid and fluid mechanics) where this technique provides substantial clarity and correspondence to mathematical notation. The suggested transformation (eliminating the temporary g[][] in exchange for fancy indexing of g) is problematic when representing higher order tensors (https://en.wikipedia.org/wiki/Voigt_notation#Mnemonic_rule). It's also sometimes desirable to roll the second loop instead of repeating, in which case you don't get to have a different indexing rule for g[j][0] and g[j][1]. for (int i=0; i
[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 --- Comment #7 from rguenther at suse dot de --- On Wed, 11 Sep 2019, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||jakub at gcc dot gnu.org > > --- Comment #4 from Jakub Jelinek --- > The endless series of vpextrb look terrible, can't that be handled by possibly > masked permutation? Sure, just nobody implemented support for that into the strided store code (likewise for strided loads). I'm also not sure it is really faster in the end. Maybe VPMULTISHIFTQB can also help.
[Bug go/91712] [10 regression] ICE in bind_field_or_method, at go/gofrontend/types.cc:11878
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91712 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Ian Lance Taylor --- Should be fixed by SVN revision 275648 (I forgot to add the PR reference to the commit message).
[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 --- Comment #8 from Richard Biener --- The most trivial improvement is likely to recognize the vector parts we can store via HImode. There's already support for that but only if we can uniformly use HImode and not a mix of sizes.
[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 --- Comment #9 from Richard Biener --- (In reply to Richard Biener from comment #8) > The most trivial improvement is likely to recognize the vector parts we can > store via HImode. There's already support for that but only if we can > uniformly > use HImode and not a mix of sizes. While for loads we need N "same" pieces to be able to build the CONSTRUCTOR for stores we can do arbitrary extracts so the strided store code could be refactored to decide on that in the main loop walking over the actual elements to store rather than computing this upfront (I sort-of copied the handling from the strided load code retaining this restriction). Might get rid of 1/3 of the pextracts.
[Bug go/91700] Document go version for gcc 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91700 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Ian Lance Taylor --- Thanks. Fixed.
[Bug target/91738] New: [10 regression] gcc.target/arm/pr53447-5.c fails since r274823
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91738 Bug ID: 91738 Summary: [10 regression] gcc.target/arm/pr53447-5.c fails since r274823 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Since r274823, this arm test fails: FAIL: gcc.target/arm/pr53447-5.c scan-assembler-times (ldrd|vldr\\.64) 20 FAIL: gcc.target/arm/pr53447-5.c scan-assembler-times (strd|vstr\\.64) 18 I open this PR to keep track of the discussion started here: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01728.html
[Bug target/91735] [9/10 Regression] Runtime regression for SPEC2000 177.mesa on Haswell around the end of August 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91735 --- Comment #10 from Richard Biener --- Can't really decipher what clang does here. it seems to handle even/odd lanes separately, doing 24 vpextrb stores per loop iteration. Possibly simply an interleaving scheme...
[Bug target/91738] [10 regression] gcc.target/arm/pr53447-5.c fails since r274823
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91738 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug tree-optimization/91734] gcc skip an if statement with "-O1 -ffast-math"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
This is:
/* sqrt(x) < c is the same as x < c*c, if we ignore NaNs. */
(if (! HONOR_NANS (@0))
(cmp @0 { build_real (TREE_TYPE (@0), c2); })
/* sqrt(x) < c is the same as x >= 0 && x < c*c. */
(if (GENERIC)
(truth_andif
(ge @0 { build_real (TREE_TYPE (@0), dconst0); })
(cmp @0 { build_real (TREE_TYPE (@0), c2); })
c here is 1.1754943508222875079687365374567781866555677208752151e-38f,
so c2 is 0.0f because the product is smaller than smallest positive subnormal
float. Obviously, in that case we can't use < c2, but need to use <= c2.
Maybe we probably should compute c2 with rounding towards positive infinity,
then we could keep using < c2.
[Bug middle-end/91739] New: Missed optimization for arithmetic operations of integers and floating point constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91739
Bug ID: 91739
Summary: Missed optimization for arithmetic operations of
integers and floating point constants
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the example:
double foo(unsigned i, unsigned j) {
return i * 4.0 + j * 7.0;
}
Right now GCC emits code that converts integers to a floating points and does
the multiplications:
foo(unsigned int, unsigned int): # @foo(unsigned int, unsigned int)
mov eax, edi
cvtsi2sd xmm1, rax
mulsd xmm1, qword ptr [rip + .LCPI0_0]
mov eax, esi
cvtsi2sd xmm0, rax
mulsd xmm0, qword ptr [rip + .LCPI0_1]
addsd xmm0, xmm1
ret
However it is possible to do better. If the max value of integer multiplied by
the floating point constant fits into the mantissa and there is an integral
type that could also hold the value then do the multiplication using integers:
double foo2(unsigned i, unsigned j) {
return i * 4ull + j * 7ull;
}
This results in a much better code:
foo2(unsigned int, unsigned int): # @foo2(unsigned int, unsigned int)
mov eax, edi
mov ecx, esi
lea rdx, [8*rcx]
sub rdx, rcx
lea rax, [rdx + 4*rax]
cvtsi2sd xmm0, rax
ret
[Bug tree-optimization/91734] gcc skip an if statement with "-O1 -ffast-math"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-11 CC||jsm28 at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Jakub Jelinek --- Likely introduced in r64619.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #9 from Manfred Schwarb --- Hi Steve, I tried your patch in comment 4, it is a good starting point. However, SNGL and DBLE still throw warnings: real*4 a,aa real*8 b,bb real*10 c,cc real*16 d integer*2 e,ee integer*4 f,ff integer*8 g,gg PARAMETER(a=3.1415927_4) PARAMETER(b=3.1415927_8) PARAMETER(c=3.1415927_10) PARAMETER(d=3.1415927_16) PARAMETER(e=123_2) PARAMETER(f=123_4) PARAMETER(g=123_8) aa=REAL(b) aa=REAL(c) aa=REAL(d) aa=REAL(e) aa=REAL(f) aa=REAL(g) aa=FLOAT(f) aa=FLOOR(b) aa=FLOOR(c) aa=FLOOR(d) aa=CEILING(b) aa=CEILING(c) aa=CEILING(d) !---unknown but documented type conversions: !!aa=FLOATI(e) !!aa=FLOATJ(f) !!aa=FLOATK(g) !---documentation is wrong for sngl: aa=SNGL(c) aa=SNGL(d) bb=REAL(c, kind=8) bb=REAL(d, kind=8) bb=DBLE(c) bb=DBLE(d) bb=DFLOAT(g) bb=FLOOR(c) bb=FLOOR(d) bb=CEILING(c) bb=CEILING(d) cc=REAL(d, kind=10) cc=FLOOR(d) cc=CEILING(d) aa=AINT(b) aa=ANINT(b) aa=AINT(c) aa=ANINT(c) aa=AINT(d) aa=ANINT(d) bb=DINT(b) bb=DNINT(b) ee=INT(a, kind=2) ee=NINT(a, kind=2) ee=INT(b, kind=2) ee=NINT(b, kind=2) ee=INT(c, kind=2) ee=NINT(c, kind=2) ee=INT(d, kind=2) ee=NINT(d, kind=2) ee=INT(f, kind=2) ee=INT(g, kind=2) ee=IFIX(a) ee=IDINT(b) ee=IDNINT(b) ee=INT2(a) ee=INT2(b) ee=INT2(c) ee=INT2(d) ee=INT2(f) ee=INT2(g) ff=INT(a, kind=4) ff=NINT(a, kind=4) ff=INT(b, kind=4) ff=NINT(b, kind=4) ff=INT(c, kind=4) ff=NINT(c, kind=4) ff=INT(d, kind=4) ff=NINT(d, kind=4) ff=INT(f, kind=4) ff=INT(g, kind=4) ff=IFIX(a) ff=IDINT(b) ff=IDNINT(b) !---LONG not allowed anymore in gfortran 10 (?): !!ff=LONG(a) !!ff=LONG(b) !!ff=LONG(c) !!ff=LONG(d) !!ff=LONG(g) gg=INT(a, kind=8) gg=NINT(a, kind=8) gg=INT(b, kind=8) gg=NINT(b, kind=8) gg=INT(c, kind=8) gg=NINT(c, kind=8) gg=INT(d, kind=8) gg=NINT(d, kind=8) gg=INT(f, kind=8) gg=INT(g, kind=8) gg=IFIX(a) gg=IDINT(b) gg=IDNINT(b) gg=INT8(a) gg=INT8(b) gg=INT8(c) gg=INT8(d) gg=INT8(g) end a.f:34:14: 34 | aa=SNGL(c) | 1 Warning: Change of value in conversion from 'REAL(10)' to 'REAL(4)' at (1) [-Wconversion] a.f:35:14: 35 | aa=SNGL(d) | 1 Warning: Change of value in conversion from 'REAL(16)' to 'REAL(4)' at (1) [-Wconversion] a.f:38:14: 38 | bb=DBLE(c) | 1 Warning: Change of value in conversion from 'REAL(10)' to 'REAL(8)' at (1) [-Wconversion] a.f:39:14: 39 | bb=DBLE(d) | 1 Warning: Change of value in conversion from 'REAL(16)' to 'REAL(8)' at (1) [-Wconversion]
[Bug tree-optimization/91734] gcc skip an if statement with "-O1 -ffast-math"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734 --- Comment #5 from Jakub Jelinek --- Even in the default rounding mode, cases where c2 is equal to zero are clearly problematic as this testcase shows, but also cases where c is subnormal. E.g. sqrtf (x) < 0x1.2dd3d0p-65f is true for x 0x1.63dbc0p-130f, because sqrtf (0x1.63dbc0p-130f) == 0x1.2dd3cep-65. But c2 is 0x1.63dbc0p-130f and so 0x1.63dbc0p-130f < 0x1.63dbc0p-130f is false. So, 1) shall we somehow guard some of these optimizations on !HONOR_SIGN_DEPENDENT_ROUNDING (or is flag_unsafe_math_optimizations it is guarded on incompatible with -frounding-math)? 2) after computing the c2, try to real_sqrt it again and if cmp is LT_EXPR or GE_EXPR, adjust cmp depending on how the boundary value compares?
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #10 from Steve Kargl --- On Wed, Sep 11, 2019 at 02:25:23PM +, manfred99 at gmx dot ch wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 > > --- Comment #9 from Manfred Schwarb --- > Hi Steve, > > I tried your patch in comment 4, it is a good starting point. > However, SNGL and DBLE still throw warnings: A patch similar to what appears in comment #4 need to be applied to gfc_simplify_dble and gfc_simplify_sngl. > !---unknown but documented type conversions: > !!aa=FLOATI(e) > !!aa=FLOATJ(f) > !!aa=FLOATK(g) The above are under the -fdec option. > !---LONG not allowed anymore in gfortran 10 (?): > !!ff=LONG(a) > !!ff=LONG(b) > !!ff=LONG(c) > !!ff=LONG(d) > !!ff=LONG(g) LONG was removed by by BOZ patch. It was documented to convert its argument to C's 32-bit long type. Not a good thing as long can be 64-bit. Note, SHORT was also removed. Fortunately, LONG and SHORT were in-line conversion, so no change to libgfortran was needed.
[Bug c++/91740] New: ICE in fold_convert_loc, at fold-const.c:2429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91740
Bug ID: 91740
Summary: ICE in fold_convert_loc, at fold-const.c:2429
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: julien at vivenot dot fr
Target Milestone: ---
The following causes an internal compiler error on gcc 9.2.0 on x86-64.
I do not have access to other versions myself but tested on godbolt: It seems
to say that 9.1, 9.2 and current trunk are affected, while 8.3 is unaffected.
$ cat test.cpp
constexpr bool f(const char*) { return true; }
template const char c = "FOO"[f("BAR") ? 1 : 0];
$ g++ test.cpp
test.cpp:2:59: internal compiler error: in fold_convert_loc, at
fold-const.c:2429
2 | template const char c = "FOO"[f("BAR") ? 1 : 0];
| ^
The current code is obviously meaningless because it has been slowly scaled
down from production code.
I have noted that any of the following changes make the issue disappear :
- removing the argument to f()
- removing the templatization
- removing the ternary operator
[Bug c++/91740] [9/10 Regression] ICE in fold_convert_loc, at fold-const.c:2429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91740 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-11 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |9.3 Summary|ICE in fold_convert_loc, at |[9/10 Regression] ICE in |fold-const.c:2429 |fold_convert_loc, at ||fold-const.c:2429 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/91740] [9/10 Regression] ICE in fold_convert_loc, at fold-const.c:2429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91740 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with r267272. Will take a look.
[Bug tree-optimization/91734] gcc skip an if statement with "-O1 -ffast-math"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734 --- Comment #6 from Jakub Jelinek --- Created attachment 46871 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46871&action=edit gcc10-pr91734.patch Untested patch that does the 2), though for LE_EXPR only.
[Bug c++/91741] New: Implement new warning -Wsizeof-array-div
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91741 Bug ID: 91741 Summary: Implement new warning -Wsizeof-array-div Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org Target Milestone: --- ... to detect things like: https://www.viva64.com/en/examples/v706/
[Bug c++/91742] New: User defined conversion references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91742
Bug ID: 91742
Summary: User defined conversion references
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: di...@franco-technologies.com
Target Milestone: ---
The following code does not work as intended:
//Example-
#include
#include
struct A
{
operator const std::vector&() const
{
return a_;
}
std::vector a_;
};
int main()
{
A a {};
const auto& b1 {static_cast&>(a)};
const std::vector& b2 {a};
assert(&a.a_ == &b1);
assert(&b1 == &b2); // does not work with gcc 8.3.0 any standard
// works with gcc 7.1.0 with c++17 only
}
//End of example-
I read through the c++17 standard and did not find any information about this
behavior being implementation defined.
Diego
[Bug c++/91742] User defined conversion references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91742 --- Comment #1 from Diego --- The code does work when changing std::vector for any primitive types, i.e. int.
[Bug c++/91741] Implement new warning -Wsizeof-array-div
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91741 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-11 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Looks like a good idea for a warning. But please don't make the diagnostic say "every element", since I hope all the elements of an array have the same size, so you don't need to consider every one of them ;-)
[Bug c++/91741] Implement new warning -Wsizeof-array-div
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91741 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- I thought we already had this, but I guess I was thinking of -Wsizeof-pointer-div instead...
[Bug c++/91742] User defined conversion references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91742 --- Comment #2 from Jonathan Wakely --- (In reply to Diego from comment #0) > I read through the c++17 standard and did not find any information about > this behavior being implementation defined. It's not implementation defined, but I think all implementations are required to do what GCC 8 does (and other compilers agree). The current behaviour started with r259123 (before that there was an ICE, introduced by r258755).
[Bug c++/91742] User defined conversion references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91742
--- Comment #3 from Jonathan Wakely ---
Reduced:
#define assert(C) if (!(C)) { __builtin_puts("Assertion failed: " #C);
__builtin_abort(); }
struct X {
X() { }
X(const X&) { }
};
struct A
{
operator const X&() const
{
return a_;
}
X a_;
};
int main()
{
A a {};
const auto& b1 {static_cast(a)};
const X& b2 {a};
assert(&a.a_ == &b1);
assert(&b1 == &b2); // does not work with gcc 8.3.0 any standard
}
Assertion failed: &b1 == &b2
Aborted (core dumped)
If "const X& b2 (a)" is used instead of list-init, the second assertion passes.
[Bug c/91743] New: ice: tree check: expected ssa_name, have mult_expr in get_nonzero_bits, at tree-ssanames.c:524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91743
Bug ID: 91743
Summary: ice: tree check: expected ssa_name, have mult_expr in
get_nonzero_bits, at tree-ssanames.c:524
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this two line C code:
a, b;
c() { unsigned long d = b * d / (1 << a); }
compiled by recent gcc trunk I get this:
bug541.c: In function ‘c’:
bug541.c:2:1: internal compiler error: tree check: expected ssa_name, have
mult_expr in get_nonzero_bits, at tree-ssanames.c:524
0x734b85 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../trunk/gcc/tree.c:9932
0x71ce8c tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../trunk/gcc/tree.h:3519
0x71ce8c get_nonzero_bits(tree_node const*)
../../trunk/gcc/tree-ssanames.c:524
0x1393e52 generic_simplify_124
/home/dcb/gcc/working/gcc/generic-match.c:5656
The bug seems to first appear sometime from revision 275550
to revision 275600.
[Bug target/91738] [10 regression] gcc.target/arm/pr53447-5.c fails since r274823
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91738 Wilco changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-09-11 CC||wilco at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Wilco --- (In reply to Christophe Lyon from comment #0) > Since r274823, this arm test fails: > > FAIL: gcc.target/arm/pr53447-5.c scan-assembler-times (ldrd|vldr\\.64) 20 > FAIL: gcc.target/arm/pr53447-5.c scan-assembler-times (strd|vstr\\.64) 18 > > I open this PR to keep track of the discussion started here: > https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01728.html Patch: https://gcc.gnu.org/ml/gcc-patches/2019-08/msg02005.html
[Bug c++/91742] User defined conversion references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91742
--- Comment #4 from Diego Franco ---
> It's not implementation defined, but I think all implementations are required
> to do what GCC 8 does (and other compilers agree).
It worked on linaro 7.4.1 gcc with c++17, gcc 7.1.0 with c++17 only.
> If "const X& b2 (a)" is used instead of list-init, the second assertion
> passes.
That seems like an issue no working with {}.
[Bug c++/91742] User defined conversion references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91742
--- Comment #5 from Jonathan Wakely ---
(In reply to Diego Franco from comment #4)
> It worked on linaro 7.4.1 gcc with c++17, gcc 7.1.0 with c++17 only.
Yes, sometimes old versions have incorrect behaviour and they get fixed.
I agree this is surprising, but it's not the only weird property of {}
initialization.
[Bug c++/91742] User defined conversion references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91742 --- Comment #6 from Diego Franco --- Also the brace initialization works with primitive types for the code I posted in the first place. That's definitely a code smell.
[Bug c++/91742] User defined conversion references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91742
--- Comment #7 from Diego Franco ---
This works:
#include
#include
struct A
{
operator const int&() const
{
return a_;
}
int a_;
};
int main()
{
A a {};
const auto& b1 {static_cast(a)};
const int& b2 {a};
assert(&a.a_ == &b1);
assert(&b1 == &b2); // works
[Bug c++/91678] [9/10 Regression] decltype returns wrong type under certain conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91678 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #2 from Marek Polacek --- Patch posted Sep 5: https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00330.html
[Bug fortran/91642] ICE: Bad IO basetype (transfer_expr, at fortran/trans-io.c:2507)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91642 --- Comment #2 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Sep 11 18:27:17 2019 New Revision: 275655 URL: https://gcc.gnu.org/viewcvs?rev=275655&root=gcc&view=rev Log: 2019-09-11 Steven G. Kargl PR fortran/91642 * io.c (gfc_match_inquire): null() cannot be in an iolength inquire list. 2019-09-11 Steven G. Kargl PR fortran/91642 * gfortran.dg/pr91642.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr91642.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/91553] ICE in gfc_real2complex, at fortran/arith.c:2208
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91553 --- Comment #2 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Sep 11 18:37:31 2019 New Revision: 275657 URL: https://gcc.gnu.org/viewcvs?rev=275657&root=gcc&view=rev Log: 2019-09-11 Steven G. Kargl PR fortran/91553 * simplify.c (gfc_convert_constant): During conversion check if the constant is enclosed in parenthesis, and simplify expression. 2019-09-11 Steven G. Kargl PR fortran/91553 * gfortran.dg/pr91553.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr91553.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog
[Bug target/85401] segfault building code for VAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401 --- Comment #5 from coypu --- Created attachment 46872 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46872&action=edit providing instruction scheduling avoids this crash So, I am trying to beat gcc/vax into shape and incorporate changes from netbsd's patches. I noticed one of the changes I made for another reason avoids this crash. It is providing a (trivial) instruction scheduling.
[Bug c/91743] ice: tree check: expected ssa_name, have mult_expr in get_nonzero_bits, at tree-ssanames.c:524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91743 David Binderman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from David Binderman --- Problem seems to have gone away by revision 275650.
[Bug target/85401] segfault building code for VAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401 --- Comment #6 from coypu --- I imagine I didn't write scheduling for the broken instruction, so it doesn't ever happen. something silly like that, rather than it being a valid fix.
[Bug c/91744] New: -fno-pie is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91744
Bug ID: 91744
Summary: -fno-pie is not honored
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: noloader at gmail dot com
Target Milestone: ---
From Initial SUPERCOP Haswell results for round 2
(https://groups.google.com/a/list.nist.gov/d/msg/pqc-forum/kiMo-1jBwDI/KS8VtDwWAgAJ):
$ cat x.c
#include
extern int thenumber(void);
int main() { printf("%d\n",thenumber()); return 0; }
$ cat y.c
static int myconstant = 5;
int thenumber(void) { return myconstant; }
And then:
$ gcc -c x.c; clang -c y.c; gcc -o x x.o y.o
/usr/bin/ld: y.o: relocation R_X86_64_32S against `.data' can not be used when
making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
And finally with -fno-pie:
$ gcc -c x.c; clang -c y.c; gcc -fno-pie -o x x.o y.o
/usr/bin/ld: y.o: relocation R_X86_64_32S against `.data' can not be used when
making a PIE object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
[Bug c/91744] -fno-pie is not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91744 --- Comment #1 from Jeffrey Walton --- My bad, this should have been included: $ lsb_release -rd Description:Ubuntu 18.04.3 LTS Release:18.04 $ gcc --version gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0 Copyright (C) 2017 Free Software Foundation, Inc.
