[Bug ipa/81360] [8 Regression] ice in estimate_edge_growth, at ipa-inline.h:86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81360 Martin Liška changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #10 from Martin Liška --- I have smaller test-case: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/pr63595.C -fno-early-inlining -O2 during IPA pass: inline /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/pr63595.C:77:1: internal compiler error: in estimate_edge_growth, at ipa-inline.h:85 } ^ 0x1e34c94 estimate_edge_growth ../../gcc/ipa-inline.h:84 0x1e36de7 want_inline_small_function_p ../../gcc/ipa-inline.c:747 0x1e38e86 update_caller_keys ../../gcc/ipa-inline.c:1320 0x1e3af13 inline_small_functions ../../gcc/ipa-inline.c:2022 0x1e3c65c ipa_inline ../../gcc/ipa-inline.c:2455 0x1e3d35a execute ../../gcc/ipa-inline.c:2861 Honza can you please take a look?
[Bug tree-optimization/83963] [8 Regression] [graphite] ICE in merge_sese, at graphite-scop-detection.c:517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83963 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-22 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with Richi's r256841.
[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- This is without -mcpu=power8, as the testcase enforces normally. The builtin expansion then creates insns that do not exist. Confirmed.
[Bug c++/83958] ICE: Segmentation fault (in find_decomp_class_base)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83958 Martin Liška changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-22 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed, started with r242377.
[Bug ada/83892] Various ICEs and link-errors with running ACATS with -O2 -g -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83892 --- Comment #5 from rguenther at suse dot de --- On Sun, 21 Jan 2018, simon at pushface dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83892 > > simon at pushface dot org changed: > >What|Removed |Added > > CC||simon at pushface dot org > > --- Comment #4 from simon at pushface dot org --- > I’ve found the same 9 fails as Eric on x86_64-apple-darwin15 with -flto -O2. > > I can’t try with -flto -O2 -g because of pr 83960. > > Please note that I’ve been working on ACATS 4.1f (the latest version, rather > than the 15-year-old version 2.5 currently in GCC), hoping to get it included > in GCC at some stage, see https://github.com/simonjwright/ACATS; I’ve just > checked in a change so that you can say for example > > make check-acats gccflags='-O2 -g -flto' > > (gccflags is the variable name in the ACATS script) and I’m wondering whether > I should choose a more specific name? e.g. ACATS_GCCFLAGS. It would be nice if acats could honor dejagnu RUNTESTFLAGS. That is, I regularly do make check RUNTESTFLAGS="--target_board=unix/-g" and that should append -g to all flags used. That might need a "simple" acats.exp to wrap the run_acats/all.sh scripts. Currently acats seems to be invoked via check-acats in gcc/ada/gcc-interface/Make-lang.in
[Bug target/83946] [7/8 Regression] Safe Indirect Jumps broken on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83946 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener --- Fixed (I assume), rolling RC2 right now.
[Bug lto/83954] [6/7/8 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-22 CC||hubicka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |8.0 Summary|LTO: Bogus |[6/7/8 Regression] LTO: |-Wlto-type-mismatch warning |Bogus -Wlto-type-mismatch |for array of pointer to |warning for array of |incomplete type |pointer to incomplete type Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r231239. Let me take a look.
[Bug middle-end/83945] [7 Regression] internal compiler error: Segmentation fault with -O -fcode-hoisting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83945 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/83947] [8 Regression] ICE on invalid C++ code with auto: in tsubst_decl, at cp/pt.c:13046
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83947 Richard Biener changed: What|Removed |Added Keywords||ice-on-invalid-code Priority|P3 |P1 Version|unknown |8.0 Target Milestone|--- |8.0 Summary|ICE on invalid C++ code |[8 Regression] ICE on |with auto: in tsubst_decl, |invalid C++ code with auto: |at cp/pt.c:13046|in tsubst_decl, at ||cp/pt.c:13046
[Bug c++/83949] internal compiler error: Segmentation fault (only with -g)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83949 --- Comment #5 from Richard Biener --- Created attachment 43201 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43201&action=edit unincluded unreduced testcase
[Bug debug/83949] internal compiler error: Segmentation fault (only with -g)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83949 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-22 Component|c++ |debug Ever confirmed|0 |1 Known to fail||7.2.1 --- Comment #6 from Richard Biener --- Confirmed with GCC 7.2.1. I suppose a "fix" could be to simply truncate/throw away those long strings from the debuginfo or emit "joint_iter"? I guess nobody wants >3GB of dwarf either...
[Bug c++/83950] [8 regression] error: no matching function for call to ‘folly::dynamic::at(size_t&) const’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83950 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Priority|P3 |P1 Target Milestone|--- |8.0
[Bug gcov-profile/83877] Make gcov accept a path to the gcda and a path to the gcno file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83877 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-22 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Reasonable request, let me do it in next stage1.
[Bug rtl-optimization/83952] [missed optimization] difference calculation for floats vs ints in a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83952 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-22 CC||amker at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #9 from Richard Biener --- The issue is we don't do IVOPTs for floats (for the given case FP would be exact). We also don't do IVOPTs for vectors (with -O3 we first vectorize the loop).
[Bug gcov-profile/83878] Line hit counts are sometimes wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83878 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-01-22 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- I guess it's caused by some base or a different constructor which is probably inlined there. Do you use -O2? Can you please attach preprocessed source file?
[Bug rtl-optimization/83952] [missed optimization] difference calculation for floats vs ints in a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83952
--- Comment #10 from Richard Biener ---
But at least we could perform strength reduction in IVOPTs, replacing
for (i = 0; i < 100; i++) {
val = 2 * i;
a[i] = val;
}
with
for (i = 0, j = 0; i < 100; i++, j+=2) {
val = j;
a[i] = val;
}
I guess we might even consider this but reject it based on costs. Iff we
then could see that j is only used in a int to float conversion we might
evaluate precision/round-off issues and elide the IV to float ...
[Bug lto/83954] [6/7/8 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/83958] [7/8 Regression] ICE: Segmentation fault (in find_decomp_class_base)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83958 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Version|unknown |8.0 Target Milestone|--- |7.3 Summary|ICE: Segmentation fault (in |[7/8 Regression] ICE: |find_decomp_class_base) |Segmentation fault (in ||find_decomp_class_base)
[Bug target/82005] [8 regression] early lto debug creates invalid assembly on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005 Richard Biener changed: What|Removed |Added CC||simon at pushface dot org --- Comment #20 from Richard Biener --- *** Bug 83960 has been marked as a duplicate of this bug. ***
[Bug c/83960] Bad assembler with debug and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83960 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener --- dup *** This bug has been marked as a duplicate of bug 82005 ***
[Bug rtl-optimization/83962] [8 Regression] ICE: verify_flow_info failed (too many outgoing branch edges from bb 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83962 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug c/83966] ICE in check_function_arguments at gcc/c-family/c-common.c:5617
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83966 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-22 Version|unknown |7.2.1 Ever confirmed|0 |1
[Bug tree-optimization/83965] [8 Regression] ICE in vectorize_fold_left_reduction, at tree-vect-loop.c:6154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83965 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Version|unknown |8.0 Target Milestone|--- |8.0
[Bug target/83964] [8 Regression] ICE in extract_insn, at recog.c:2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83964 Richard Biener changed: What|Removed |Added Version|unknown |8.0 Target Milestone|--- |8.0
[Bug tree-optimization/83963] [8 Regression] [graphite] ICE in merge_sese, at graphite-scop-detection.c:517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83963 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine.
[Bug tree-optimization/83963] [8 Regression] [graphite] ICE in merge_sese, at graphite-scop-detection.c:517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83963 --- Comment #3 from Richard Biener --- Ok, I knew this assert would fire...
[Bug sanitizer/83961] AddressSanitizer CHECK failed on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83961 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek --- AFAIK AArch64 has multiple configurable sizes of the virtual address space and older GCCs like 6 was only supporting one of those sizes, not all of them. So, when not using GCC 7 or later, one has to patch libsanitizer when not using the address space size in the kernel that the library is expecting. This is a distro problem IMHO. Marking as fixed in GCC 7, WONTFIX for older versions.
[Bug ipa/81360] [8 Regression] ice in estimate_edge_growth, at ipa-inline.h:86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81360 --- Comment #11 from Jan Hubicka --- Hmm, this is different issue introduced by Richard's change to reorder can inline and want inline. 2018-01-14 Richard Sandiford * ipa-inline.c (want_inline_small_function_p): Return false if inlining has already failed with CIF_FINAL_ERROR. (update_caller_keys): Call want_inline_small_function_p before can_inline_edge_p. (update_callee_keys): Likewise. We want the very basic tests to come first i guess Honza
[Bug tree-optimization/83965] [8 Regression] ICE in vectorize_fold_left_reduction, at tree-vect-loop.c:6154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83965 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-22 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/81443] [7/8 regression] build/genrecog.o: virtual memory exhausted: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443 --- Comment #14 from Eric Botcazou --- It's rather a combinatorial explosion than an unbounded recursion.
[Bug debug/83935] DWARF for a variant part is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935 Pierre-Marie de Rodat changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-22 CC||derodat at adacore dot com Component|ada |debug Assignee|unassigned at gcc dot gnu.org |derodat at adacore dot com Ever confirmed|0 |1 --- Comment #1 from Pierre-Marie de Rodat --- Hello Tom, I agree with your interpretation of the standard. I did not notice that part when I implemented DW_TAG_variant_part generation several years ago. I’ll try to fix that. Note however that since GCC is in stage 4, it’s likely that the fix will not be accepted in trunk until we switch back to stage 5 (in April, I guess). In any case, thank you for reporting this!
[Bug c++/71892] Recent optimization changes introduce bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71892 dnahrblock changed: What|Removed |Added CC||howunijemu at crypemail dot info --- Comment #15 from dnahrblock --- http://www.talktowendys.xyz/ Jan-2018 TalktoWendys.com Take Wendy's Survey Here Jan 9, 2018 - Take TalktoWendys Survey or Wendy's survey here at www.talktowendys.com. Check the post for details related to Wendys customer satisfaction survey.
[Bug libstdc++/27931] valgrind reports memleak when std::ios:sync_with_stdio(false)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27931 dnahrblock changed: What|Removed |Added CC||howunijemu at crypemail dot info --- Comment #6 from dnahrblock --- My BK Experience – Burger King Survey for Burger King Free Whopper http://www.mybk-experience.xyz/ Dec 21, 2017 - Who loves burgers? And who loves Free Whopper Burger King? Yes, you can start accessing MyBKExperience.com to take My BK Experience Survey. Here the steps..
[Bug middle-end/34300] gcc 4.2.2 miscompiles code that uses global register variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34300 dnahrblock changed: What|Removed |Added CC||howunijemu at crypemail dot info --- Comment #11 from dnahrblock --- How to Participate in McDonald's Survey on Vimeo ... Customer Satisfaction Survey official website, take part in the survey and receive a coupon code to redeem the ... http://www.mcd-voice.xyz
[Bug c/49915] Function call with 2-D arrays and -O2 (or strict-aliasing and inlining) gives random results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49915 dnahrblock changed: What|Removed |Added CC||howunijemu at crypemail dot info --- Comment #3 from dnahrblock --- Taco Bell Tell The Bell Customer Survey Sweepstakes 2018 - Winzily Jan 4, 2018 - Taco Bell Tell The Bell Customer Survey Sweepstakes 2018. Tell the Bell and you could win $500 cash. Visit tellthebell.com and complete the Taco Bell Customer Satisfaction Survey to be automatically entered into the Taco Bell Tell The Bell Sweepstakes. You could be one of the weekly Tell The Bell ... http://www.tellthebell.xyz/
[Bug libstdc++/65018] Use secure_getenv when available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65018 dnahrblock changed: What|Removed |Added CC||howunijemu at crypemail dot info --- Comment #2 from dnahrblock --- Working at H&R Block: 7,105 Reviews | Indeed.com 7105 reviews from H&R Block employees about H&R Block culture, salaries, benefits, work-life balance, management, job security, and more. http://www.dnahrblock.xyz/
[Bug gcov-profile/83879] __gcov_dump doesn't work with dlopen-ed libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83879 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-22 CC||nathan at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, problem is that we create 2 shared libraries that both have __gcov_master symbol defined. When dlopen is used for the library: #0 __gcov_init (info=0x77817160) at ../../../libgcc/libgcov-driver.c:904 #1 0x77614070 in _GLOBAL__sub_I_00100_0_func.c () from ./func.shared #2 0x77de6b8a in call_init (l=, argc=argc@entry=1, argv=argv@entry=0x7fffdbe8, env=env@entry=0x7fffdbf8) at dl-init.c:72 #3 0x77de6c96 in call_init (env=0x7fffdbf8, argv=0x7fffdbe8, argc=1, l=) at dl-init.c:119 #4 _dl_init (main_map=main_map@entry=0x607280, argc=1, argv=0x7fffdbe8, env=0x7fffdbf8) at dl-init.c:120 #5 0x77deb3ee in dl_open_worker (a=a@entry=0x7fffd880) at dl-open.c:564 #6 0x7794d7c4 in __GI__dl_catch_error (objname=0x7fffd870, errstring=0x7fffd878, mallocedp=0x7fffd86f, operate=0x77deb060 , args=0x7fffd880) at dl-error-skeleton.c:198 #7 0x77deab99 in _dl_open (file=0x4034b8 "func.shared", mode=-2147483391, caller_dlopen=0x400e6f , nsid=-2, argc=, argv=, env=0x7fffdbf8) at dl-open.c:649 Then we end up with situation where __gcov_master from main.c is different from the ones living in the shared libraries. And then we end with multiple __gcov_master symbols which is wrong. The symbol should live in the process image just once. Nathan any ideas how to fix that?
[Bug debug/83935] DWARF for a variant part is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935 --- Comment #2 from Pierre-Marie de Rodat --- Thinking more about it, the rule that the discriminant entry must be a child of the variant part entry sounds suspicious to me. In the case of two variant parts, which are nested and depend on the same discriminant, where should the discriminant entry go? If it’s in the outer one, then it’s not a child of the nested one, violating the rule, and conversely. We could duplicate the dicriminant entry, but that does not look friendly DWARF consumer at all: two member entries would have the same name. And that sounds like a waste of space. Here’s the Ada example: -- $ gcc -c -g -fgnat-encodings=minimal pck.ads). package Pck is type Rec (I : Integer) is record case I is when Positive => C : Character; case I is when 0 => null; when others => N : Natural; end case; when others => S : String (1 .. 10); end case; end record; R : Rec (1); end Pck; And now, even though it’s illegal in Ada (it could be legal in another language): what about two variant parts that have the same discriminant and that are not nested? I guess I should report these questions to the DWARF discussion mailing list. What do you think, Tom?
[Bug lto/83967] New: LTO removes C functions declared as weak in assembler(depending on files order in linking)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967 Bug ID: 83967 Summary: LTO removes C functions declared as weak in assembler(depending on files order in linking) Product: gcc Version: 7.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: hurwic8 at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- I've observed strange behaviour of the link-time optimization on GCC 7.2.1, exact version: gcc version 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204] (GNU Tools for Arm Embedded Processors 7-2017-q4-major) I have project that is compiled for the microcontroller. In startup file, that is written in assembler, there are weak definitions of the interrupt handlers. Some of those weak functions are defined in the project C files. Strange behaviour occurs when I set -flto flag on GCC 7.2.1: during optimization, the defined in C files interrupt functions are perceived as unused and removed(replaced by its weak definitions) - I've checked that in the .map file. This issue does not occur when startup file is first on the source files list, which is given as an argument to the linker. If I change order of source files, all interrupt handlers from C files, that are placed on the source files list before startup are removed and replaced by weak definitions from startup. For me it seems that linker is removing interrupt handler functions before noticing its usage in startup file. Or maybe weak function definitions from startup override definitions from C files. I've checked if this issue happens on the GCC 4.9.3 - it worked fine, so this is rather new behaviour. I've also confirmed this bug with other developer from Germany: https://www.mikrocontroller.net/topic/443262 Take a look at the latest posts, which are written in English. Is this a bug or should I place some extra pragmas/attributes to extort proper linker behaviour? Please let me know if you want me to prepare some basic examples of this issue.
[Bug rtl-optimization/80481] Unoptimal additional copy instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80481 Andrew Senkevich changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Andrew Senkevich --- Several workloads from CPU2017 also improved a bit. Thanks.
[Bug libstdc++/61458] std::aligned_storage is bigger than expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61458 --- Comment #11 from Jonathan Wakely --- That's not an ABI break. Changing it now would be an ABI break.
[Bug target/83969] New: [8 Regression] ICE in final_scan_insn, at final.c:2997 (error: could not split insn) for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83969
Bug ID: 83969
Summary: [8 Regression] ICE in final_scan_insn, at final.c:2997
(error: could not split insn) for powerpc targets
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu
gcc-8.0.0-alpha20180121 snapshot (r256935) ICEs when compiling the following
snippet w/ -mcpu=G5 (7400, 7450, 970, G4, cell, e6500) -O1 (-O2, -O3, -Ofast)
-ftree-loop-vectorize -fno-split-wide-types:
long long int
n7 (int po, long long int r4)
{
while (po < 1)
{
r4 |= 1;
++po;
}
return r4;
}
% powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180121 -mcpu=G5 -O1
-ftree-loop-vectorize -fno-split-wide-types -c rpzs7fm3.c
rpzs7fm3.c: In function 'n7':
rpzs7fm3.c:11:1: error: could not split insn
}
^
(insn 29 28 99 (set (reg:TI 8 8 [orig:128 vect_r4_6.4 ] [128])
(mem/c:TI (plus:SI (reg/f:SI 1 1)
(reg:SI 3 3 [154])) [0 S16 A128])) "rpzs7fm3.c":6 614
{*movti_string}
(nil))
during RTL pass: final
rpzs7fm3.c:11:1: internal compiler error: in final_scan_insn, at final.c:2997
0x54cbf8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/rtl-error.c:108
0x88b8fe final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/final.c:2997
0x88bcb7 final(rtx_insn*, _IO_FILE*, int)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/final.c:1999
0x88c26a rest_of_handle_final
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/final.c:4485
0x88c26a execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/final.c:4559
[Bug c++/83958] [7/8 Regression] ICE: Segmentation fault (in find_decomp_class_base)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83958 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 43204 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43204&action=edit gcc8-pr83958.patch Untested fix.
[Bug target/83969] [8 Regression] ICE in final_scan_insn, at final.c:2997 (error: could not split insn) for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83969 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967 Richard Biener changed: What|Removed |Added Keywords||lto, wrong-code Target||arm Status|UNCONFIRMED |WAITING Last reconfirmed||2018-01-22 CC||rguenth at gcc dot gnu.org Host||x86_64-linux Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- If you have two weak definitions it is undefined which one takes precedence. If the C project variant (that gets removed?) is not weak the linker should have made it used. But this is only going to work if you build with a linker plugin - so can you double check that (for example pass -fuse-linker-plugin to the link step?). In any case we'd need something like a testcase to confirm/investigate. Please also specify the linker you are using. I assume you are cross compiling from x86_64-linux?
[Bug sanitizer/83961] AddressSanitizer CHECK failed on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83961 --- Comment #3 from Jeffrey Walton --- (In reply to Jakub Jelinek from comment #2) > AFAIK AArch64 has multiple configurable sizes of the virtual address space > and older GCCs like 6 was only supporting one of those sizes, not all of > them. > So, when not using GCC 7 or later, one has to patch libsanitizer when not > using the address space size in the kernel that the library is expecting. > This is a distro problem IMHO. > Marking as fixed in GCC 7, WONTFIX for older versions. Thanks Jakub, I'd like to say GCC should patch 6 but I don't know how big a job that is. It sounds like it is more than a few lines of code so I can't beg for it. I'm guessing libasan never should have been installed in the first place. I guess an uninstall of libasan is in order for GCC117. Would you happen to know how to tell when libasan is not compatible with the host's OS? A related question is, where are the docs on properly configuring libasan during build time? This may be the preferred option, but people need to know how to do it. Thanks.
[Bug target/83970] New: -mindirect-branch=thunk -fno-plt generates CET-incompatible thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83970
Bug ID: 83970
Summary: -mindirect-branch=thunk -fno-plt generates
CET-incompatible thunk
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
Target: x86
[hjl@gnu-bdx-1 indirect-got-1]$ cat x.i
void func (void);
void
bar (void)
{
func ();
}
[hjl@gnu-bdx-1 indirect-got-1]$
/export/build/gnu/gcc-test/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-test/build-x86_64-linux/gcc/ -O2
-mindirect-branch=thunk -fno-plt -S x.i
[hjl@gnu-bdx-1 indirect-got-1]$ cat x.s
.file "x.i"
.text
.p2align 4,,15
.globl bar
.type bar, @function
bar:
.LFB0:
.cfi_startproc
pushq func@GOTPCREL(%rip)
jmp __x86_indirect_thunk
.cfi_endproc
.LFE0:
.size bar, .-bar
.section
.text.__x86_indirect_thunk,"axG",@progbits,__x86_indirect_thunk,comdat
.globl __x86_indirect_thunk
.hidden __x86_indirect_thunk
.type __x86_indirect_thunk, @function
__x86_indirect_thunk:
.set__x86_return_thunk,__x86_indirect_thunk
.globl __x86_return_thunk
.hidden __x86_return_thunk
.LFB1:
.cfi_startproc
call.LIND1
.LIND0:
pause
lfence
jmp .LIND0
.LIND1:
lea 8(%rsp), %rsp
ret
.cfi_endproc
.LFE1:
.ident "GCC: (GNU) 8.0.1 20180115 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-bdx-1 indirect-got-1]$
For i386, since all registers may be used for function call, there
isn't much we can do. But there are a couple scratch registers
available for function call. We can generate
bar:
.LFB0:
.cfi_startproc
movqfunc@GOTPCREL(%rip), %r11
jmp __x86_indirect_thunk_r11
.cfi_endproc
.LFE0:
.size bar, .-bar
which is easier to change __x86_indirect_thunk_r11 to be compatible
with CET.
[Bug tree-optimization/83957] ICE: Segmentation fault (in gimple_phi_arg)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83957 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-22 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jakub Jelinek --- Created attachment 43205 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43205&action=edit gcc8-pr83957.patch Untested fix.
[Bug c++/83895] [8 Regression] -Wparentheses warns about pointer-to-member typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83895 --- Comment #2 from ville at gcc dot gnu.org --- Author: ville Date: Mon Jan 22 12:44:33 2018 New Revision: 256942 URL: https://gcc.gnu.org/viewcvs?rev=256942&root=gcc&view=rev Log: PR c++/83895 cp/ * decl.c (grokdeclarator): Don't diagnose extra parens on typedefs. testsuite/ * g++.dg/warn/83895.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/83895.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c
[Bug c++/83895] [8 Regression] -Wparentheses warns about pointer-to-member typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83895 Ville Voutilainen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Ville Voutilainen --- Fixed.
[Bug ada/83892] Various ICEs and link-errors with running ACATS with -O2 -g -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83892 --- Comment #6 from simon at pushface dot org --- I tried check-gnat, which also shows additional lto-related failures. Running with lto shows 5 additional FAILs (and 3 fewer PASSes???) LTO: Running target unix/-flto/-g0 ... === gnat Summary === # of expected passes2673 # of unexpected failures16 # of expected failures 24 # of unsupported tests 7 /Volumes/Miscellaneous/tmp/gcc-256927-build/gcc/gnatmake version 8.0.1 20180121 (experimental) No LTO: Running target unix/-g ... === gnat Summary === # of expected passes2676 # of unexpected failures11 # of expected failures 24 # of unsupported tests 7 /Volumes/Miscellaneous/tmp/gcc-256927-build/gcc/gnatmake version 8.0.1 20180121 (experimental)
[Bug tree-optimization/83963] [8 Regression] [graphite] ICE in merge_sese, at graphite-scop-detection.c:517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83963 --- Comment #4 from Richard Biener --- Author: rguenth Date: Mon Jan 22 13:10:57 2018 New Revision: 256943 URL: https://gcc.gnu.org/viewcvs?rev=256943&root=gcc&view=rev Log: 2018-01-22 Richard Biener PR tree-optimization/83963 * graphite-scop-detection.c (scop_detection::get_sese): Delay including the loop exit block. (scop_detection::merge_sese): Likewise. (scop_detection::add_scop): Do it here instead. * gcc.dg/graphite/pr83963.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr83963.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-scop-detection.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/83704] pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704 --- Comment #18 from Janne Blomqvist --- Author: jb Date: Mon Jan 22 13:31:08 2018 New Revision: 256944 URL: https://gcc.gnu.org/viewcvs?rev=256944&root=gcc&view=rev Log: PR 78534, 83704 Large character lengths This patch fixes various parts of the code to use a larger type than int for the character length. Depending on the situation, HOST_WIDE_INT, size_t, or gfc_charlen_t is appropriate. Regtested on x86_64-pc-linux-gnu and i686-pc-linux-gnu. gcc/fortran/ChangeLog: 2018-01-22 Janne Blomqvist PR 78534 PR 83704 * arith.c (gfc_arith_concat): Use size_t for string length. (gfc_compare_string): Likewise. (gfc_compare_with_Cstring): Likewise. * array.c (gfc_resolve_character_array_constructor): Use HOST_WIDE_INT, gfc_mpz_get_hwi. * check.c (gfc_check_fe_runtime_error): Use size_t. * data.c (create_character_initializer): Use HOST_WIDE_INT, gfc_extract_hwi. * decl.c (gfc_set_constant_character_len): Use gfc_charlen_t. (add_init_expr_to_sym): Use HOST_WIDE_INT. * expr.c (gfc_build_init_expr): Use HOST_WIDE_INT, gfc_extract_hwi. (gfc_apply_init): Likewise. * match.h (gfc_set_constant_character_len): Update prototype. * primary.c (match_string_constant): Use size_t. * resolve.c (resolve_ordinary_assign): Use HOST_WIDE_INT, gfc_mpz_get_hwi. * simplify.c (init_result_expr): Likewise. (gfc_simplify_len_trim): Use size_t. * target-memory.c (gfc_encode_character): Use size_t. (gfc_target_encode_expr): Use HOST_WIDE_INT, gfc_mpz_get_hwi. (interpret_array): Use size_t. (gfc_interpret_character): Likewise. * target-memory.h (gfc_encode_character): Update prototype. (gfc_interpret_character): Likewise. (gfc_target_interpret_expr): Likewise. * trans-const.c (gfc_build_string_const): Use size_t for length argument. (gfc_build_wide_string_const): Likewise. * trans-const.h (gfc_build_string_const): Likewise. (gfc_build_wide_string_const): Likewise. 2018-01-22 Janne Blomqvist PR 78534 PR 83704 * gfortran.dg/string_1.f90: Remove printing the length. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/array.c trunk/gcc/fortran/check.c trunk/gcc/fortran/data.c trunk/gcc/fortran/decl.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/match.h trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/target-memory.c trunk/gcc/fortran/target-memory.h trunk/gcc/fortran/trans-const.c trunk/gcc/fortran/trans-const.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/string_1.f90
[Bug fortran/83898] [6/7/8 Regression] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:7181
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83898 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- Created attachment 43206 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43206&action=edit Fix for the PR Not regtested yet. Paul
[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534 --- Comment #25 from Janne Blomqvist --- Author: jb Date: Mon Jan 22 13:31:08 2018 New Revision: 256944 URL: https://gcc.gnu.org/viewcvs?rev=256944&root=gcc&view=rev Log: PR 78534, 83704 Large character lengths This patch fixes various parts of the code to use a larger type than int for the character length. Depending on the situation, HOST_WIDE_INT, size_t, or gfc_charlen_t is appropriate. Regtested on x86_64-pc-linux-gnu and i686-pc-linux-gnu. gcc/fortran/ChangeLog: 2018-01-22 Janne Blomqvist PR 78534 PR 83704 * arith.c (gfc_arith_concat): Use size_t for string length. (gfc_compare_string): Likewise. (gfc_compare_with_Cstring): Likewise. * array.c (gfc_resolve_character_array_constructor): Use HOST_WIDE_INT, gfc_mpz_get_hwi. * check.c (gfc_check_fe_runtime_error): Use size_t. * data.c (create_character_initializer): Use HOST_WIDE_INT, gfc_extract_hwi. * decl.c (gfc_set_constant_character_len): Use gfc_charlen_t. (add_init_expr_to_sym): Use HOST_WIDE_INT. * expr.c (gfc_build_init_expr): Use HOST_WIDE_INT, gfc_extract_hwi. (gfc_apply_init): Likewise. * match.h (gfc_set_constant_character_len): Update prototype. * primary.c (match_string_constant): Use size_t. * resolve.c (resolve_ordinary_assign): Use HOST_WIDE_INT, gfc_mpz_get_hwi. * simplify.c (init_result_expr): Likewise. (gfc_simplify_len_trim): Use size_t. * target-memory.c (gfc_encode_character): Use size_t. (gfc_target_encode_expr): Use HOST_WIDE_INT, gfc_mpz_get_hwi. (interpret_array): Use size_t. (gfc_interpret_character): Likewise. * target-memory.h (gfc_encode_character): Update prototype. (gfc_interpret_character): Likewise. (gfc_target_interpret_expr): Likewise. * trans-const.c (gfc_build_string_const): Use size_t for length argument. (gfc_build_wide_string_const): Likewise. * trans-const.h (gfc_build_string_const): Likewise. (gfc_build_wide_string_const): Likewise. 2018-01-22 Janne Blomqvist PR 78534 PR 83704 * gfortran.dg/string_1.f90: Remove printing the length. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/array.c trunk/gcc/fortran/check.c trunk/gcc/fortran/data.c trunk/gcc/fortran/decl.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/match.h trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/target-memory.c trunk/gcc/fortran/target-memory.h trunk/gcc/fortran/trans-const.c trunk/gcc/fortran/trans-const.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/string_1.f90
[Bug fortran/83704] pr31243 revisited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704 Janne Blomqvist changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #19 from Janne Blomqvist --- The -Wcharacter-truncation warning should now be fixed by r256944, closing.
[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616 --- Comment #45 from Jan Hubicka --- I believe all issues tracked here has been adressed. Andrew, do you still see some anomalies? Honza
[Bug lto/83954] [6/7/8 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954 --- Comment #2 from Dan Bonachea --- Thanks Mr. Liška! If possible it would be useful for our project to know whether this defect is solely a spurious warning, or whether it could affect analysis in a way that might result in incorrect code generation on affected compiler versions (as suggested by the warning text). Assuming it's the latter, can anyone suggest any non-intrusive workarounds? (aside from the obvious "big hammers" of -fno-lto or -fno-strict-aliasing)
[Bug tree-optimization/83963] [8 Regression] [graphite] ICE in merge_sese, at graphite-scop-detection.c:517
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83963 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug target/83399] Power8 ICE During LRA with 2-op rtl pattern for lvx instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83399 Segher Boessenkool changed: What|Removed |Added Target Milestone|--- |6.5
[Bug lto/83954] [6/7/8 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #3 from Martin Liška ---
Slightly reduced test-case:
$ cat lto.h
struct foo;
extern struct foo *FOO_PTR_ARR[1];
$ cat lto1.c
#include "lto.h"
int main() {
// just to prevent symbol removal
FOO_PTR_ARR[1] = 0;
return 0;
}
$ cat lto2.c
#include "lto.h"
struct foo {
int x;
};
struct foo *FOO_PTR_ARR[1] = { 0 };
We end up comparison following 2 types in ODR mismatch:
(gdb) p debug_tree(type)
pointer_to_this chain >
unsigned DI
size
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set 1 structural-equality>
DI size unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set 1 structural-equality
domain unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76828738 precision:64 min max >
DI size unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76828738 precision:64 min max >
pointer_to_this >
$3 = void
(gdb) p debug_tree(prevailing_type)
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76a0ddc8 fields context
pointer_to_this chain >
unsigned DI
size
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set 2 structural-equality>
DI size unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set 2 structural-equality
domain unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76828738 precision:64 min max >
DI size unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76828738 precision:64 min max >>
Honza can you please take a look?
[Bug lto/83954] [6/7/8 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954 --- Comment #4 from Martin Liška --- > Assuming it's the latter, can anyone suggest any non-intrusive workarounds? > (aside from the obvious "big hammers" of -fno-lto or -fno-strict-aliasing) Yes, the warning should not produce bogus warnings. Proper solution is not to break strict aliasing. Note that it can help optimization to make more aggressive optimizations.
[Bug rtl-optimization/80463] [6/7/8 Regression] ICE with -fselective-scheduling2 and -fvar-tracking-assignments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80463
--- Comment #13 from Andrey Belevantsev ---
(In reply to Andrey Belevantsev from comment #12)
> (In reply to Arseny Solokha from comment #11)
> > How about this one? It makes only trunk gcc ICE, though.
> >
> > short int t2;
> > int cd, aa, ft;
> >
> > void
> > dh (void)
> > {
> > int qs = 0;
> >
> > if (t2 < 1)
> > {
> > int bq = 0;
> >
> > while (bq < 1)
> > {
> > }
> >
> > while (t2 < 1)
> > {
> > if (t2 == 0)
> > {
> > bq = 0;
> > cd = !!cd;
> > }
> > else
> > {
> > bq = 1;
> > cd = bq > qs;
> > }
> >
> > t2 += cd;
> > bq = (t2 / qs) == bq;
> >
> > if (aa != ft)
> > {
> > qs %= 0;
> > while (bq != 0)
> > {
> > ro:
> > ;
> > }
> > }
> >
> > ++t2;
> > }
> >
> > ia:
> > goto ro;
> > }
> >
> > goto ia;
> > }
> >
> > % gcc-8.0.0-alpha20180114 -O2 -fvar-tracking-assignments
> > -fselective-scheduling2 -ftree-loop-vectorize -fnon-call-exceptions
> > -fno-tree-vrp -fno-gcse-lm -fno-tree-loop-im
> > -fno-reorder-blocks-and-partition -fno-reorder-blocks
> > -fno-move-loop-invariants -w -c rsd2aiem.c
> > during RTL pass: sched2
> > rsd2aiem.c: In function 'dh':
> > rsd2aiem.c:51:1: internal compiler error: in
> > av_set_could_be_blocked_by_bookkeeping_p, at sel-sched.c:3622
> > }
> > ^
> > 0x64ad85 av_set_could_be_blocked_by_bookkeeping_p
> >
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:3622
> > 0x64ad85 code_motion_process_successors
> >
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:6395
> > 0x64ad85 code_motion_path_driver
> >
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:6617
> > 0xc59886 code_motion_process_successors
> >
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:6351
> > 0xc59886 code_motion_path_driver
> >
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:6617
> > 0xc59886 code_motion_process_successors
> >
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:6351
> > 0xc59886 code_motion_path_driver
> >
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:6617
> > 0xc5aa5a find_used_regs
> >
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:3283
> > 0xc5aa5a collect_unavailable_regs_from_bnds
> >
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:1598
> > 0xc5aa5a find_best_reg_for_expr
> >
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:1661
> > 0xc5aa5a fill_vec_av_set
> >
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:3797
> > 0xc5da87 fill_ready_list
> >
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:4027
> > 0xc5da87 find_best_expr
> >
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:4387
> > 0xc5da87 fill_insns
> >
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:5544
> > 0xc5da87 schedule_on_fences
> >
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:7361
> > 0xc5da87 sel_sched_region_2
> >
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:7499
> > 0xc61737 sel_sched_region_1
> >
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:7541
> > 0xc61737 sel_sched_region(int)
> >
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:7642
> > 0xc627a8 run_selective_scheduling()
> >
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sel-sched.c:7718
> > 0xc42625 rest_of_handle_sched2
> >
> > /var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180114/work/gcc-8-20180114/gcc/
> > sched-rgn.c:3729
> >
> > (as of r256677)
>
> Give me a few more days for unrelated stuff and I'll have enough time to
> look at this. If that turns to be the same dependence issue, we can check
> in a patch without waiting for hot/cold bbs issue to be sorted out.
So this one is unrelated to the original testcase. What happens is we have a
usual if then else control flow like this: bb 4 --> bb 5, bb 6; bb 5 --> bb 7;
bb 6 --> bb 7. There is a debug stmt in bb 6 sayng bq i
[Bug lto/83954] [6/7/8 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954 --- Comment #5 from Dan Bonachea --- (In reply to Martin Liška from comment #4) > > Assuming it's the latter, can anyone suggest any non-intrusive workarounds? > > (aside from the obvious "big hammers" of -fno-lto or -fno-strict-aliasing) > > Yes, the warning should not produce bogus warnings. Proper solution is not > to break strict aliasing. Note that it can help optimization to make more > aggressive optimizations. I'm confused - are you saying the test program actually breaks C's strict aliasing rules? My understanding was this is a correct (spec-compliant) C program that is being mishandled by gcc. My question was whether this mishandling could generally result in actual incorrect optimization of programs encountering this defect, and it sounds like you are saying it might?
[Bug lto/83954] [6/7/8 Regression] LTO: Bogus -Wlto-type-mismatch warning for array of pointer to incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83954 --- Comment #6 from Martin Liška --- (In reply to Dan Bonachea from comment #5) > (In reply to Martin Liška from comment #4) > > > Assuming it's the latter, can anyone suggest any non-intrusive > > > workarounds? > > > (aside from the obvious "big hammers" of -fno-lto or -fno-strict-aliasing) > > > > Yes, the warning should not produce bogus warnings. Proper solution is not > > to break strict aliasing. Note that it can help optimization to make more > > aggressive optimizations. > > I'm confused - are you saying the test program actually breaks C's strict > aliasing rules? My understanding was this is a correct (spec-compliant) C > program that is being mishandled by gcc. My question was whether this > mishandling could generally result in actual incorrect optimization of > programs encountering this defect, and it sounds like you are saying it > might? Yes, it's a valid C program. And yes, it's mishandled by GCC. I believe considering these two types as having different alias sets can result in an incorrect optimization.
[Bug c/83971] New: gcc -static link command hardcoded when --with-system-libunwind used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83971 Bug ID: 83971 Summary: gcc -static link command hardcoded when --with-system-libunwind used Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jason.duerstock at gmail dot com Target Milestone: --- Created attachment 43207 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43207&action=edit example build log Modern versions of libunwind include liblzma for decompressing compressed symbol tables. So when gcc is built with --with-system-libunwind, static links will fail because gcc is hardcoded to use "-lunwind" rather than the results of "pkg-config --libs --static libunwind". As a result, liblzma.a is not included when it should be. See https://buildd.debian.org/status/fetch.php?pkg=libdebug&arch=ia64&ver=0.5.2-2&stamp=1516055815&raw=0 for a full build log. The problem seems to stem from gcc/gcc.c:init_spec()
[Bug lto/81440] -Wlto-type-mismatch warning with flexible array in struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81440 --- Comment #4 from Dan Halbert --- There's movement on bug 83954, which seems related but is a different manifestation. Will a fix there fix this also? (I see your "I've got a patch" comment, but that was a while ago).
[Bug driver/83971] gcc -static link command hardcoded when --with-system-libunwind used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83971 Andrew Pinski changed: What|Removed |Added Component|c |driver --- Comment #1 from Andrew Pinski --- Usually --with-system-libunwind is only used on ia64 and no other target.
[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967 --- Comment #2 from Andrew Pinski --- Also I was going to say the c function maybe should be marked as used as lto likes to remove unused functions in general.
[Bug lto/81440] -Wlto-type-mismatch warning with flexible array in struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81440 --- Comment #5 from Martin Liška --- (In reply to Dan Halbert from comment #4) > There's movement on bug 83954, which seems related but is a different > manifestation. Will a fix there fix this also? (I see your "I've got a > patch" comment, but that was a while ago). Sorry, I forgot about it. Let me push it..
[Bug gcov-profile/83879] __gcov_dump doesn't work with dlopen-ed libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83879 --- Comment #2 from Nathan Sidwell --- The multiple definitions of gcov_master should not be a problem. The (ELF) semantics of shared libraries are such that the definition in the main program preempts the defiitions in the libraries. The libraries' GOT entry for that symbol should point at the main program's instance. That's the design intent, IIRC. It looks like the shared objects are built with PIC libgcov: <__gcov_dump_int>: 0: 48 8b 05 00 00 00 00mov0x0(%rip),%rax# 7 <__gcov_dump_int+0x7> 3: R_X86_64_REX_GOTPCRELX __gcov_master-0x4 7: 53 push %rbx 8: 48 8d 1d 00 00 00 00lea0x0(%rip),%rbx# f <__gcov_dump_int+0xf> b: R_X86_64_PC32__gcov_root-0x4 f: 81 38 52 32 37 41 cmpl $0x41373252,(%rax) So I presume that during loading the shared objects, they're not linking themselves into the gcov list.
[Bug rtl-optimization/83973] New: ICE in code_motion_process_successors, at sel-sched.c:6398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83973
Bug ID: 83973
Summary: ICE in code_motion_process_successors, at
sel-sched.c:6398
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-checking
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: abel at gcc dot gnu.org
Target Milestone: ---
gcc-8.0.0-alpha20180121 snapshot (r256935), 6.3, 5.4, 4.9.4 all ICE when
compiling the following snippet w/ -O2 -fselective-scheduling2
-fnon-call-exceptions -ftree-vectorize -fvar-tracking-assignments:
int xj, dp;
void
b4 (int p9)
{
goto ir;
while (xj < 1)
{
xj = 1;
p9 /= 0;
if (p9 == 0)
dp = 0;
if (dp == 0)
{
ir:
while (p9 < 2)
{
}
}
++xj;
}
}
% gcc-8.0.0-alpha20180121 -O2 -fselective-scheduling2 -fnon-call-exceptions
-ftree-vectorize -fvar-tracking-assignments -w -c q4x7agro.c
during RTL pass: sched2
q4x7agro.c: In function 'b4':
q4x7agro.c:26:1: internal compiler error: in code_motion_process_successors, at
sel-sched.c:6398
}
^
0xc604c9 code_motion_process_successors
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:6395
0xc604c9 code_motion_path_driver
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:6617
0xc5ffee code_motion_process_successors
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:6351
0xc5ffee code_motion_path_driver
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:6617
0xc606c2 move_op
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:6709
0xc606c2 move_exprs_to_boundary
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:5232
0xc606c2 schedule_expr_on_boundary
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:5445
0xc6472c fill_insns
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:5587
0xc6472c schedule_on_fences
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:7361
0xc6472c sel_sched_region_2
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:7499
0xc66588 sel_sched_region_1
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:7541
0xc66588 sel_sched_region(int)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:7642
0xc675f1 run_selective_scheduling()
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:7718
0xc46ed5 rest_of_handle_sched2
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sched-rgn.c:3729
0xc46ed5 execute
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sched-rgn.c:3873
[Bug rtl-optimization/83972] New: ICE in code_motion_process_successors, at sel-sched.c:6398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83972
Bug ID: 83972
Summary: ICE in code_motion_process_successors, at
sel-sched.c:6398
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: abel at gcc dot gnu.org
Target Milestone: ---
gcc-8.0.0-alpha20180121 snapshot (r256935), 7.2, 5.4, 4,9,4 all ICE when
compiling the following snippet w/ -O1 -fschedule-insns -fselective-scheduling
-fsel-sched-pipelining -fvar-tracking-assignments -funroll-loops
-fno-tree-dominator-opts:
int s7, p0;
void
i0 (int ke)
{
while (ke < 1)
{
if (s7 == 0)
p0 = 0;
else
{
if (p0 == 0)
s7 = 0;
if (!!s7 || !!p0)
s7 = 0;
else
p0 = 0;
}
++ke;
}
}
% gcc-8.0.0-alpha20180121 -O1 -fschedule-insns -fselective-scheduling
-fsel-sched-pipelining -fvar-tracking-assignments -funroll-loops
-fno-tree-dominator-opts -w -c ljfxtywm.c
during RTL pass: sched1
ljfxtywm.c: In function 'i0':
ljfxtywm.c:23:1: internal compiler error: in code_motion_process_successors, at
sel-sched.c:6398
}
^
0xc604c9 code_motion_process_successors
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:6395
0xc604c9 code_motion_path_driver
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:6617
0xc5ffee code_motion_process_successors
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:6351
0xc5ffee code_motion_path_driver
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:6617
0xc606c2 move_op
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:6709
0xc606c2 move_exprs_to_boundary
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:5232
0xc606c2 schedule_expr_on_boundary
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:5445
0xc6472c fill_insns
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:5587
0xc6472c schedule_on_fences
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:7361
0xc6472c sel_sched_region_2
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:7499
0xc66588 sel_sched_region_1
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:7541
0xc66588 sel_sched_region(int)
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:7642
0xc675f1 run_selective_scheduling()
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sel-sched.c:7718
0xc46e7d rest_of_handle_sched
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sched-rgn.c:3715
0xc46e7d execute
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180121/work/gcc-8-20180121/gcc/sched-rgn.c:3825
[Bug rtl-optimization/80463] [6/7/8 Regression] ICE with -fselective-scheduling2 and -fvar-tracking-assignments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80463 --- Comment #14 from Arseny Solokha --- Thank you for the analysis. I can fill a separate PR for this testcase if that's more appropriate. Meanwhile, I got two more testcases which I've just reported as PR83972 and PR83973 not to clutter this PR too much, though both of them may be actually duplicates of this one.
[Bug c++/81933] [7/8 Regression] Invalid "constexpr call flows off the end of the function" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81933 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Mon Jan 22 16:05:20 2018 New Revision: 256951 URL: https://gcc.gnu.org/viewcvs?rev=256951&root=gcc&view=rev Log: PR c++/81933 * typeck2.c (split_nonconstant_init_1): Return false if we didn't split out anything. * g++.dg/cpp1y/constexpr-empty4.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-empty4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/81933] [7 Regression] Invalid "constexpr call flows off the end of the function" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81933 Marek Polacek changed: What|Removed |Added Summary|[7/8 Regression] Invalid|[7 Regression] Invalid |"constexpr call flows off |"constexpr call flows off |the end of the function"|the end of the function" |error |error --- Comment #8 from Marek Polacek --- Fixed on trunk so far.
[Bug driver/83971] gcc -static link command hardcoded when --with-system-libunwind used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83971 --- Comment #2 from Jason Duerstock --- At least tangentially related, what's the reason only ia64 needs libunwind? What happens if gcc is built with --disable-libunwind-exceptions? I haven't been able to find a clear explanation regarding this anywhere.
[Bug c/83966] ICE in check_function_arguments at gcc/c-family/c-common.c:5617
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83966 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I'll take a look.
[Bug gcov-profile/83879] __gcov_dump doesn't work with dlopen-ed libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83879
--- Comment #3 from Nathan Sidwell ---
Aha, this is the behaviour of the static linker. It is not placing
'__gcov_master' into main's dynamic symbol table. So dlloading the shared
objects do not see it, and have their own instance. To confuse things further,
the first dlloaded object creates this symbol and the second loaded object sees
that symbol.
from ld's man page:
When creating a dynamically linked executable, using the -E option or
the --export-dynamic option causes the linker
to add all symbols to the dynamic symbol table. The dynamic symbol
table is the set of symbols which are visible
from dynamic objects at run time.
If you do not use either of these options (or use the
--no-export-dynamic option to restore the default behavior),
the dynamic symbol table will normally contain only those symbols
which are referenced by some dynamic object
mentioned in the link.
If you use "dlopen" to load a dynamic object which needs to refer
back to the symbols defined by the program, rather
than some other dynamic object, then you will probably need to use
this option when linking the program itself.
You can also use the dynamic list to control what symbols should be
added to the dynamic symbol table if the output
format supports it. See the description of --dynamic-list.
Note that this option is specific to ELF targeted ports. PE targets
support a similar function to export all symbols
from a DLL or EXE; see the description of --export-all-symbols
below.
You can use '-dynamic' when invoking gcc to set this linker flag:
Pass the flag @option{-export-dynamic} to the ELF linker, on targets
that support it. This instructs the linker to add all symbols, not
only used ones, to the dynamic symbol table. This option is needed
for some uses of @code{dlopen} or to allow obtaining backtraces
from within a program.
Might be worth documenting this in gcov's options?
[Bug target/80547] [6/7/8 Regression] nvptx back end ICE with OpenACC "reduction(OP:x)", "x = [...]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80547 --- Comment #5 from cesar at gcc dot gnu.org --- I wasn't able to reproduce the nvptx ICE in og7. However, the host fallback does segfault at runtime in og7.
[Bug rtl-optimization/83972] ICE in code_motion_process_successors, at sel-sched.c:6398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83972 --- Comment #1 from Dominique d'Humieres --- *** Bug 83973 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/83973] ICE in code_motion_process_successors, at sel-sched.c:6398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83973 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres --- Duplicate of pr83972. *** This bug has been marked as a duplicate of bug 83972 ***
[Bug lto/83720] [8 Regression] ICE: in mangle_decl, at cp/mangle.c:3847
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83720 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug debug/83935] DWARF for a variant part is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935 --- Comment #3 from Tom Tromey --- (In reply to Pierre-Marie de Rodat from comment #2) > Thinking more about it, the rule that the discriminant entry must be a child > of the variant part entry sounds suspicious to me. TBH this did not make sense to me, either, which is partly why I originally wrote my patch the "more natural" way -- then this got caught in review, see https://reviews.llvm.org/D42082 > I guess I should report these questions to the DWARF discussion mailing > list. What do you think, Tom? It's worth a shot, though I think it was tried before, see http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2006-August/001710.html
[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758 --- Comment #16 from acsawdey at gcc dot gnu.org --- Created attachment 43208 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43208&action=edit split-stack related bug test case
[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758 --- Comment #17 from acsawdey at gcc dot gnu.org --- Seems to be some interaction between split-stack and inlining. The ICE does not occur when compiling with -O2 -fdisable-ipa-inline.
[Bug c++/83974] New: [8 Regression] ICE in cxx_eval_constant_expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83974
Bug ID: 83974
Summary: [8 Regression] ICE in cxx_eval_constant_expression
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
struct A {
typedef void (A::*B) ();
operator B ();
};
template
struct C {
void foo () { d == 0; }
A d;
};
ICEs on the trunk, likely starting with r256804.
Either constexpr.c needs to be taught to handle various
processing_template_decl only tree codes, or we should have caught it earlier,
like somewhere in is_nondependent_constant_expression or functions it calls.
[Bug fortran/67804] ICE on data initialization of type(character) with wrong data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67804 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #2 from G. Steinmetz --- Update, backtrace : $ cat z4.f90 program p type t character :: c end type type(t) :: z data z /t(4)/ end $ gfortran-8-20180121 -c z4.f90 z4.f90:1:0: program p internal compiler error: in gfc_conv_string_init, at fortran/trans-const.c:149 0x76267a gfc_conv_string_init(tree_node*, gfc_expr*) ../../gcc/fortran/trans-const.c:149 0x780f6f gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc/fortran/trans-expr.c:6899 0x7814d5 gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gcc/fortran/trans-expr.c:7762 0x780fa1 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc/fortran/trans-expr.c:6892 0x76b152 gfc_get_symbol_decl(gfc_symbol*) ../../gcc/fortran/trans-decl.c:1822 0x76e027 generate_local_decl ../../gcc/fortran/trans-decl.c:5539 0x732bcb do_traverse_symtree ../../gcc/fortran/symbol.c:4157 0x76ec82 generate_local_vars ../../gcc/fortran/trans-decl.c:5739 0x76ec82 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6386 0x6fecd0 translate_all_program_units ../../gcc/fortran/parse.c:6103 0x6fecd0 gfc_parse_file() ../../gcc/fortran/parse.c:6306 0x74520f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204 --- While initializing directly : $ cat z5.f90 program p type t character :: c end type type(t) :: z = t(4) end $ gfortran-8-20180121 -c z5.f90 z5.f90:5:20: type(t) :: z = t(4) 1 Error: Can't convert INTEGER(4) to CHARACTER(1) at (1)
[Bug c++/83974] [8 Regression] ICE in cxx_eval_constant_expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83974 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-22 CC||dmalcolm at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- I should note that it ICEs only with -Wall or -Wtautological-compare.
[Bug fortran/83975] New: [8 Regression] ICE in set_parm_default_def_partition, at tree-ssa-coalesce.c:1919
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83975 Bug ID: 83975 Summary: [8 Regression] ICE in set_parm_default_def_partition, at tree-ssa-coalesce.c:1919 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20171217 and 20180107 : $ cat z1.f90 subroutine s(x) character(*) :: x associate (y => x) end associate end $ gfortran-8-20171217 -c z1.f90 $ $ gfortran-8-20180121 -c z1.f90 during RTL pass: expand z1.f90:1:0: subroutine s(x) internal compiler error: in set_parm_default_def_partition, at tree-ssa-coalesce.c:1919 0xc72efc set_parm_default_def_partition ../../gcc/tree-ssa-coalesce.c:1919 0xc72e07 for_all_parms ../../gcc/tree-ssa-coalesce.c:1023 0xc74798 get_parm_default_def_partitions(_var_map*) ../../gcc/tree-ssa-coalesce.c:1936 0xc2099b remove_ssa_form ../../gcc/tree-outof-ssa.c:971 0xc2099b rewrite_out_of_ssa(ssaexpand*) ../../gcc/tree-outof-ssa.c:1174 0x805810 execute ../../gcc/cfgexpand.c:6218
[Bug fortran/83975] [8 Regression] ICE in set_parm_default_def_partition, at tree-ssa-coalesce.c:1919
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83975 --- Comment #1 from G. Steinmetz --- Configured with --enable-checking=yes : $ gfortran-8-20180121-chk -c z1.f90 z1.f90:1:0: subroutine s(x) internal compiler error: tree check: expected parm_decl, have var_decl in assign_parm_find_data_types, at function.c:2456 0x61e2e1 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/tree.c:9337 0x9e9224 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc/tree.h:3132 0x9e9224 assign_parm_find_data_types ../../gcc/function.c:2456 0x9ef55b gimplify_parameters(gimple**) ../../gcc/function.c:4014 0xa5eccc gimplify_body(tree_node*, bool) ../../gcc/gimplify.c:12631 0xa5f084 gimplify_function_tree(tree_node*) ../../gcc/gimplify.c:12800 0x8aed87 cgraph_node::analyze() ../../gcc/cgraphunit.c:670 0x8b2483 analyze_functions ../../gcc/cgraphunit.c:1131 0x8b2f92 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2691
[Bug fortran/83976] New: ICE in gfc_add_component_ref, at fortran/class.c:211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83976 Bug ID: 83976 Summary: ICE in gfc_add_component_ref, at fortran/class.c:211 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Gives an ICE with version 7/8, bailed out with 5/6 : $ cat z1.f90 program p type t integer :: a end type class(t), allocatable :: x type(t) :: z = t(3) x = z z = (x) end $ gfortran-8-20180121 -c z1.f90 f951: internal compiler error: Segmentation fault 0xb90cbf crash_signal ../../gcc/toplev.c:325 0x688946 gfc_add_component_ref(gfc_expr*, char const*) ../../gcc/fortran/class.c:211 0x70ace4 resolve_ordinary_assign ../../gcc/fortran/resolve.c:10333 0x712a25 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11165 0x71507a resolve_codes ../../gcc/fortran/resolve.c:16465 0x71517e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16500 0x6feafa resolve_all_program_units ../../gcc/fortran/parse.c:6042 0x6feafa gfc_parse_file() ../../gcc/fortran/parse.c:6292 0x74520f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204
[Bug fortran/83976] ICE in gfc_add_component_ref, at fortran/class.c:211
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83976 --- Comment #1 from G. Steinmetz --- This variant works as expected : $ cat z2.f90 program p type t integer :: a end type class(t), allocatable :: x type(t) :: z = t(3) x = z z = x print *, z end $ gfortran-8-20180121 z2.f90 -static-libgfortran $ a.out 3 $
[Bug fortran/83977] New: [8 Regression] ICE in simd_clone_clauses_extract, at omp-simd-clone.c:184
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83977 Bug ID: 83977 Summary: [8 Regression] ICE in simd_clone_clauses_extract, at omp-simd-clone.c:184 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20170924 and 20171008 : $ cat z1.f90 integer function f(a, b) integer :: a, b !$omp declare simd uniform(b) linear(ref(a):b) a = a + 1 !$omp parallel call sub !$omp end parallel end $ gfortran-8-20170924 -c z1.f90 -fopenmp $ $ gfortran-8-20180121 -c z1.f90 -fopenmp during IPA pass: simdclone z1.f90:8:0: end internal compiler error: in simd_clone_clauses_extract, at omp-simd-clone.c:184 0x1279348 simd_clone_clauses_extract ../../gcc/omp-simd-clone.c:183 0x1279348 expand_simd_clones ../../gcc/omp-simd-clone.c:1599 0x1279348 ipa_omp_simd_clone ../../gcc/omp-simd-clone.c:1690 0x1279348 execute ../../gcc/omp-simd-clone.c:1718
[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758 David Edelsohn changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #18 from David Edelsohn --- +honza for ipa-inline
[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616 --- Comment #46 from Andrew Roberts --- With the latest snapshot: gcc version 8.0.1 20180121 For the mt19937ar things now look reasonable without any strange options on Ryzen. Top 5 mt19937ar took 226849 clocks -march=amdfam10 -mtune=btver2 mt19937ar took 228970 clocks -march=amdfam10 -mtune=barcelona mt19937ar took 229494 clocks -march=bdver1 -mtune=btver1 mt19937ar took 229524 clocks -march=nano -mtune=nano mt19937ar took 230003 clocks -march=opteron-sse3 -mtune=athlon64-sse3 mt19937ar took 233793 clocks -march=k8-sse3 -mtune=x86-64 mt19937ar took 241700 clocks -march=corei7 -mtune=generic mt19937ar took 242373 clocks -march=nano-3000 -mtune=znver1 mt19937ar took 245550 clocks -march=k8-sse3 -mtune=haswell mt19937ar took 251431 clocks -march=znver1 -mtune=generic mt19937ar took 262200 clocks -march=znver1 -mtune=znver1 mt19937ar took 276993 clocks -march=haswell -mtune=haswell Bot 5 mt19937ar took 341326 clocks -march=nano-x4 -mtune=silvermont mt19937ar took 341750 clocks -march=core-avx-i -mtune=nocona mt19937ar took 342457 clocks -march=k8 -mtune=znver1 mt19937ar took 347453 clocks -march=ivybridge -mtune=bonnell mt19937ar took 364041 clocks -march=haswell -mtune=core-avx-i with -mno-avx2 mt19937ar took 235997 clocks -march=znver1 -mtune=opteron mt19937ar took 233921 clocks -march=nano-1000 -mtune=x86-64 mt19937ar took 243452 clocks -march=znver1 -mtune=x86-64 mt19937ar took 243540 clocks -march=silvermont -mtune=generic mt19937ar took 247113 clocks -march=znver1 -mtune=generic mt19937ar took 241368 clocks -march=nano-2000 -mtune=haswell mt19937ar took 247806 clocks -march=znver1 -mtune=znver1 Compare this with it taking 430875 clocks originally for -march=znver1 -mtune=znver1 On Haswell Top 5 mt19937ar took 22 clocks -march=amdfam10 -mtune=amdfam10 mt19937ar took 22 clocks -march=amdfam10 -mtune=athlon64 mt19937ar took 22 clocks -march=amdfam10 -mtune=athlon64-sse3 mt19937ar took 22 clocks -march=amdfam10 -mtune=athlon-fx mt19937ar took 22 clocks -march=amdfam10 -mtune=barcelona mt19937ar took 22 clocks -march=corei7-avx -mtune=x86-64 mt19937ar took 23 clocks -march=haswell -mtune=haswell mt19937ar took 24 clocks -march=haswell -mtune=generic mt19937ar took 26 clocks -march=haswell -mtune=x86-64 Bot 5 (all various shades of mtune=bdverZ or mtune=btverZ) mt19937ar took 31 clocks -march=core-avx2 -mtune=bdver1 mt19937ar took 31 clocks -march=haswell -mtune=bdver1 mt19937ar took 31 clocks -march=skylake -mtune=bdver1
[Bug debug/83935] DWARF for a variant part is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935 --- Comment #4 from Pierre-Marie de Rodat --- (In reply to Tom Tromey from comment #3) > TBH this did not make sense to me, either, which is partly why I originally > wrote my patch the "more natural" way -- then this got caught in review, > see https://reviews.llvm.org/D42082 Thanks for the pointer. So first, thanks for your efforts in adding support for these tags in GDB! During the review, Paul said: > Adding a TAG_variant_part that had no children could also work, although it > seems a little odd and might trip up an unwary non-Rust-aware debugger. Well, for now, we do generate child-less variant parts for Ada types such as: type Integer_Option (B : Boolean) is record case B is when False => null; when True => Value : Integer; end record; So I hope non-Rust-aware debuggers can cope with this. ;-) > It's worth a shot, though I think it was tried before, see > http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2006-August/ > 001710.html Ah, I see. Looks like I have the same reasoning that Ron and Todd with respect to variant parts nesting had 12 years ago! :-D Everybody seems to agree that having a top-level member to serve as a variant part’s discriminant is a good thing to have, and it’s even suggested to post a proposal to reword the troublesome paragraph. So I suggest we indeed post a submission on dwarf-discuss@ and leave GCC’s DWARF back-end as it is today. What do you think? It’s a bit late for me, so I’ll give it a try tomorrow.
[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616 --- Comment #47 from Andrew Roberts --- Again with the latest snapshot: gcc version 8.0.1 20180121 matrix.c is still needing additional options to get the best out of the Ryzen processor. But is better than before (223029 clocks vs 371978 originally), but 122677 is achievable with the right options. However the same can also be said for haswell as things stand. The haswell (-march=haswell -mtune=haswell) time has dropped from 19 to 23000, but do we put that down to Meltdown/Spectre updates or compiler updates. With just -O3 on Ryzen: Top 5 mult took 115669 clocks -march=ivybridge -mtune=skylake-avx512 mult took 118403 clocks -march=corei7-avx -mtune=skylake-avx512 mult took 119379 clocks -march=core-avx-i -mtune=skylake-avx512 mult took 119735 clocks -march=corei7-avx -mtune=skylake mult took 119901 clocks -march=sandybridge -mtune=broadwell mult took 120023 clocks -march=sandybridge -mtune=haswell mult took 121010 clocks -march=corei7-avx -mtune=haswell mult took 127371 clocks -march=sandybridge -mtune=x86-64 mult took 151208 clocks -march=btver2 -mtune=generic mult took 152360 clocks -march=ivybridge -mtune=generic mult took 173926 clocks -march=haswell -mtune=haswell mult took 177359 clocks -march=znver1 -mtune=athlon64 mult took 18 clocks -march=ivybridge -mtune=znver1 mult took 188219 clocks -march=znver1 -mtune=generic mult took 199721 clocks -march=znver1 -mtune=x86-64 mult took 223029 clocks -march=znver1 -mtune=znver1 Bot 5 mult took 377398 clocks -march=znver1 -mtune=bdver3 mult took 377650 clocks -march=knl -mtune=bdver3 mult took 378600 clocks -march=core-avx2 -mtune=bonnell mult took 381447 clocks -march=skylake-avx512 -mtune=haswell mult took 388837 clocks -march=skylake-avx512 -mtune=bdver4 On Haswell Top 5 mult took 133704 clocks -march=ivybridge -mtune=k8-sse3 mult took 15 clocks -march=btver2 -mtune=k8 mult took 15 clocks -march=core-avx-i -mtune=x86-64 mult took 15 clocks -march=corei7-avx -mtune=nano mult took 15 clocks -march=corei7-avx -mtune=opteron mult took 16 clocks -march=core-avx-i -mtune=haswell mult took 19 clocks -march=haswell -mtune=eden-x4 mult took 19 clocks -march=ivybridge -mtune=generic mult took 20 clocks -march=haswell -mtune=x86-64 mult took 23 clocks -march=haswell -mtune=haswell mult took 27 clocks -march=haswell -mtune=generic Bot 5 mult took 42 clocks -march=skylake-avx512 -mtune=bdver2 mult took 42 clocks -march=znver1 -mtune=bdver3 mult took 42 clocks -march=znver1 -mtune=bdver4 mult took 43 clocks -march=bdver2 -mtune=bdver2 mult took 43 clocks -march=knl -mtune=bdver2 Using -mprefer-vector-width=none -mno-fma -mno-avx2 -O3 On Ryzen Top 5 mult took 116558 clocks -march=haswell -mtune=bdver3 mult took 116673 clocks -march=haswell -mtune=skylake mult took 117268 clocks -march=sandybridge -mtune=skylake-avx512 mult took 117288 clocks -march=broadwell -mtune=nocona mult took 118450 clocks -march=corei7-avx -mtune=haswell mult took 119719 clocks -march=core-avx-i -mtune=znver1 mult took 120028 clocks -march=znver1 -mtune=skylake mult took 122677 clocks -march=znver1 -mtune=znver1 mult took 123423 clocks -march=haswell -mtune=haswell mult took 127388 clocks -march=skylake -mtune=x86-64 mult took 130475 clocks -march=znver1 -mtune=x86-64 mult took 132374 clocks -march=sandybridge -mtune=generic mult took 162317 clocks -march=znver1 -mtune=generic Bot 5 mult took 30 clocks -march=nano-x2 -mtune=btver2 mult took 31 clocks -march=skylake-avx512 -mtune=westmere mult took 319772 clocks -march=knl -mtune=sandybridge mult took 32 clocks -march=eden-x2 -mtune=amdfam10 mult took 33 clocks -march=atom -mtune=broadwell On Haswell Top 5 mult took 123148 clocks -march=bonnell -mtune=ivybridge mult took 130262 clocks -march=ivybridge -mtune=silvermont mult took 135299 clocks -march=core-avx2 -mtune=nano-3000 mult took 15 clocks -march=core-avx2 -mtune=intel mult took 15 clocks -march=haswell -mtune=btver1 mult took 17 clocks -march=core-avx-i -mtune=haswell mult took 17 clocks -march=znver1 -mtune=x86-64 mult took 18 clocks -march=haswell -mtune=haswell mult took 18 clocks -march=znver1 -mtune=generic mult took 21 clocks -march=haswell -mtune=generic mult took 23 clocks -march=haswell -mtune=x86-64 Bot 5 mult took 35 clocks -march=nano-x4 -mtune=nano-2000 mult took 35 clocks -march=slm -mtune=skylake-avx512 mult took 36 clocks -march=barcelona -mtune=broadwell mult took 36 clocks -march=nano -mtune=corei7 mult took 36 clocks -march=nocona -mtune=btver2
[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616 --- Comment #48 from Andrew Roberts --- Correction, that should be 23 not 23000 for the haswell drop in performance.
[Bug c++/83978] New: [8 Regression] ICE in determine_visibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83978
Bug ID: 83978
Summary: [8 Regression] ICE in determine_visibility
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
template
struct A { A () { auto a = [] { enum E {}; }; } };
A<0> *p = new A<0> ();
ICEs starting with r251433. Seems to break many Qt/KDE packages.
