[Bug target/84148] CET shouldn't be enabled in 32-bit run-time libraries by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84148 Gianluigi Tiesi changed: What|Removed |Added CC||sherpya at netfarm dot it --- Comment #3 from Gianluigi Tiesi --- I get illegal instruction on a AMD GEODE (something like i586): processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 10 model name : Geode(TM) Integrated Processor by AMD PCS stepping: 2 cpu MHz : 498.044 cache size : 128 KB fdiv_bug: no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow cpuid 3dnowprefetch vmmcall bugs: sysret_ss_attrs spectre_v1 spectre_v2 bogomips: 996.08 clflush size: 32 cache_alignment : 32 address sizes : 32 bits physical, 32 bits virtual power management: simple testcase: __asm volatile("endbr32");
[Bug ada/84320] New: Program_Error exp_util.adb:4352 explicit raise related to lock-free protected type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84320 Bug ID: 84320 Summary: Program_Error exp_util.adb:4352 explicit raise related to lock-free protected type Product: gcc Version: 7.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: matsilvabustos at abc dot gob.ar Target Milestone: --- Created attachment 43390 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43390=edit main.adb GNAT will raise Program_Error exp_util.adb:4352 by the combination of these three declarations: - a protected type declaration with Lock_Free aspect set to True - subtyping that protected type - declaring a record field of this subtype Attached main.adb. [mat@localhost src]$ LC_ALL=posix gcc -c main.adb -Wall -Wextra -gnatd.n -v Using built-in specs. COLLECT_GCC=gcc OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 7.2.1 20170915 (Red Hat 7.2.1-2) (GCC) COLLECT_GCC_OPTIONS='-c' '-Wall' '-Wextra' '-gnatd.n' '-v' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-redhat-linux/7/gnat1 -gnatwa -quiet -dumpbase main.adb -auxbase main -Wall -Wextra -gnatd.n -mtune=generic -march=x86-64 main.adb -o /tmp/ccS0v9B8.s /usr/lib/gcc/x86_64-redhat-linux/7/adainclude/system.ads main.adb +===GNAT BUG DETECTED==+ | 7.2.1 20170915 (Red Hat 7.2.1-2) (x86_64-redhat-linux) Program_Error exp_util.adb:4352 explicit raise| | Error detected at main.adb:29:4 | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). main.adb compilation abandoned
[Bug fortran/84074] Incorrect indexing of array when actual argument is an array expression and dummy is polymorphic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84074 Dominique d'Humieres changed: What|Removed |Added Keywords||wrong-code Status|RESOLVED|NEW CC||pault at gcc dot gnu.org Resolution|DUPLICATE |--- --- Comment #4 from Dominique d'Humieres --- This PR is not fixed by revision r257550, thus is not an exact duplicate of pr56691.
[Bug c++/84289] warning: variable uninitialized, emit right check only with O(1,2,3) optimisation level (in try/catch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84289 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Summary|warning : variabile |warning: variable |unitialized, emit right |uninitialized, emit right |check only with O(1,2,3)|check only with O(1,2,3) |optimisation level (in |optimisation level (in |try/catch) |try/catch) --- Comment #3 from Eric Gallager --- (In reply to claudio daffra from comment #2) > yes, but people expects g++ emit warning , Independent from optimisation > level , referring others simlar bug . can you fix ? Once the other similar bug is fixed, this one will be fixed, too. (I'm just here to fix the title so it shows up when searching)
[Bug middle-end/84089] [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C -std=gnu++14 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84089 --- Comment #9 from John David Anglin --- Author: danglin Date: Sat Feb 10 20:04:59 2018 New Revision: 257553 URL: https://gcc.gnu.org/viewcvs?rev=257553=gcc=rev Log: Backport from mainline 2018-02-01 Aldy HernandezPR target/84089 * config/pa/predicates.md (base14_operand): Handle VOIDmode. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/pa/predicates.md
[Bug middle-end/84089] [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C -std=gnu++14 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84089 --- Comment #8 from John David Anglin --- Author: danglin Date: Sat Feb 10 19:55:06 2018 New Revision: 257552 URL: https://gcc.gnu.org/viewcvs?rev=257552=gcc=rev Log: Backport from mainline 2018-02-01 Aldy HernandezPR target/84089 * config/pa/predicates.md (base14_operand): Handle VOIDmode. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/pa/predicates.md
[Bug fortran/56691] [OOP] Allocatable array: wrong offset when passing to CLASS dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56691 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED CC||pault at gcc dot gnu.org Resolution|--- |FIXED --- Comment #12 from Paul Thomas --- Fixed on trunk. Thanks for the report, Marco. Paul
[Bug fortran/84155] [8 Regression] program hangs on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155 --- Comment #22 from Jürgen Reuter --- I just started building r257550 of the trunk and will check our code. I'll report back of there are any issues.
[Bug fortran/84155] [8 Regression] program hangs on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155 Paul Thomas changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #21 from Paul Thomas --- Refixed following comment #18, for which thanks. Although I retained the caching of the dtype in GFC_TYPE_ARRAY_DTYPE, I checked that it is not used anywhere. I will try removing it altogether in the near future. Paul
[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 Bug 84141 depends on bug 84155, which changed state. Bug 84155 Summary: [8 Regression] program hangs on valid code https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/84114] global reassociation pass prevents fma usage, generates slower code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84114 --- Comment #3 from Wilco --- (In reply to Richard Biener from comment #1) > This is probably related to targetm.sched.reassociation_width where reassoc > will widen a PLUS chain so several instructions will be executable in > parallel > without dependences. Thus, (x + (y + (z + w))) -> (x + y) + (z + w). When > all of them are fed by multiplications this goes from four fmas to two. > > It's basically a target request we honor so it works as designed. > > At some point I thought about integrating FMA detection with reassociation. It should understand FMA indeed, A*B + p[0] + C*D + p[1] + E*F + p[2] can become(((p[0] + p[1] + p[2]) + A*B) + C*D) + E*F. Also we're missing a reassociation depth parameter. You need to be able to specify how long a chain needs to be before it is worth splitting - the example shows a chain of 5 FMAs is not worth splitting since FMA latency on modern cores is low, but if these were integer operations (not MADD) then the chain should be split.
[Bug fortran/84155] [8 Regression] program hangs on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155 --- Comment #20 from Paul Thomas --- Author: pault Date: Sat Feb 10 18:16:14 2018 New Revision: 257550 URL: https://gcc.gnu.org/viewcvs?rev=257550=gcc=rev Log: 2018-02-10 Paul ThomasPR fortran/84141 PR fortran/84155 * trans-array.c (gfc_array_init_size): Revert the change made in revision 257356 setting the dtype. * trans-types.c (gfc_get_dtype): Do not use the cached dtype. Call gfc_get_dtype_rank_type every time. PR fortran/56691 * trans-array.c (gfc_conv_expr_descriptor): If the source array is a descriptor type, use its offset, removing the condition that is be a class expression. 2018-02-10 Paul Thomas PR fortran/56691 * gfortran.dg/type_to_class_4.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/type_to_class_4.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/84141] [8 regression] Internal error: type_name(): Bad type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141 --- Comment #38 from Paul Thomas --- Author: pault Date: Sat Feb 10 18:16:14 2018 New Revision: 257550 URL: https://gcc.gnu.org/viewcvs?rev=257550=gcc=rev Log: 2018-02-10 Paul ThomasPR fortran/84141 PR fortran/84155 * trans-array.c (gfc_array_init_size): Revert the change made in revision 257356 setting the dtype. * trans-types.c (gfc_get_dtype): Do not use the cached dtype. Call gfc_get_dtype_rank_type every time. PR fortran/56691 * trans-array.c (gfc_conv_expr_descriptor): If the source array is a descriptor type, use its offset, removing the condition that is be a class expression. 2018-02-10 Paul Thomas PR fortran/56691 * gfortran.dg/type_to_class_4.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/type_to_class_4.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/56691] [OOP] Allocatable array: wrong offset when passing to CLASS dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56691 --- Comment #11 from Paul Thomas --- Author: pault Date: Sat Feb 10 18:16:14 2018 New Revision: 257550 URL: https://gcc.gnu.org/viewcvs?rev=257550=gcc=rev Log: 2018-02-10 Paul ThomasPR fortran/84141 PR fortran/84155 * trans-array.c (gfc_array_init_size): Revert the change made in revision 257356 setting the dtype. * trans-types.c (gfc_get_dtype): Do not use the cached dtype. Call gfc_get_dtype_rank_type every time. PR fortran/56691 * trans-array.c (gfc_conv_expr_descriptor): If the source array is a descriptor type, use its offset, removing the condition that is be a class expression. 2018-02-10 Paul Thomas PR fortran/56691 * gfortran.dg/type_to_class_4.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/type_to_class_4.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/84219] [8 Regression] ICE: Invalid expression in gfc_target_interpret_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84219 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- I had better take it. Paul
[Bug fortran/84244] [7/8 Regression] ICE in recompute_tree_invariant_for_addr_expr, at tree.c:4535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84244 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #1) > Confirmed. Revision r243909 (2016-12-23) compiles, r244868 (2017-01-24) > gives the ICE. Andre made a number of coarray commits between those dates. Paul
[Bug sanitizer/83987] [6/7 Regression] ICE with OpenMP, sanitizer and virtual bases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83987 Jakub Jelinek changed: What|Removed |Added Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with |OpenMP, sanitizer and |OpenMP, sanitizer and |virtual bases |virtual bases --- Comment #9 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug rtl-optimization/84308] [7 Regression] Memory leak in spread_components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84308 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Summary|[7/8 Regression] Memory |[7 Regression] Memory leak |leak in spread_components |in spread_components --- Comment #3 from Jakub Jelinek --- Fixed on the trunk so far.
[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 #7 from simon at pushface dot org --- (In reply to rguent...@suse.de from comment #5) > 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 I have a patch to do this, but (a) I’ve just seen that you said "append", (b) if the added switches include -gnat, you’d need to make sure you only ran "make check-acats" - -g looks like a debug option (c) RUNTESTFLAGS doesn’t get transmitted to the sub-makes in the check-acats target if you 'make -j'
[Bug fortran/84276] Invalid error for valid statement function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84276 --- Comment #14 from Steve Kargl --- On Sat, Feb 10, 2018 at 02:20:20AM +, mecej4 at outlook dot com wrote: > > Will keyword arguments in statement function references be retained as a GNU > extension? > The extension will remain, but I intend to hope a new bug report about the issue.
[Bug debug/84319] [8 regression] Location views break bootstrap with Solaris/SPARC as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84319 Rainer Orth changed: What|Removed |Added Target Milestone|--- |8.0
[Bug debug/84319] New: [8 regression] Location views break bootstrap with Solaris/SPARC as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84319 Bug ID: 84319 Summary: [8 regression] Location views break bootstrap with Solaris/SPARC as Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: aoliva at gcc dot gnu.org Target Milestone: --- Host: sparc-sun-solaris2.* Target: sparc-sun-solaris2.* Build: sparc-sun-solaris2.* The location views patch breaks bootstrap on Solaris/SPARC with the native as. The picture is a bit complicated because some builds fail earlier due to the SEGV described in PR debug/84317. Here's the overview: as/ld gas/ld gas/gld as/ld-64 gas/ld-64 s10 segvsegvsegvdiff ok s11 diffsegvsegvdiff ok s11.4 ok ok ok diff ??? (s11 is Solaris 11.3, s11.4 is Solaris 11.4 Beta) The `diff' cases fail like this (e.g. compiling the 64-bit libstdc++-v3/src/c++11/iostream-inst.cc) with -fPIC: /usr/ccs/bin/as: "iostream-inst.s", line 26808: error: can't compute difference between symbols in different segments .uahalf .LLM93-.LLM92 .LLM93: .text._ZNSt14basic_iostreamIwSt11char_traitsIwEED1Ev%_ZNSt14basic_iostreamIwSt11char_traitsIwEED1Ev .LLM92: .text._ZNSt14basic_iostreamIwSt11char_traitsIwEED0Ev%_ZNSt14basic_iostreamIwSt11char_traitsIwEED0Ev /usr/ccs/bin/as: "iostream-inst.s", line 26813: error: can't compute difference between symbols in different segments .uahalf .LLM94-.LLM93 .LLM94: .text._ZNSdD1Ev%_ZNSdD1Ev with -dA: /usr/ccs/bin/as: "iostream-inst.s", line 30361: error: can't compute difference between symbols in different segments .uaxword.LLM92 .byte 0x1 ! copy line 856 .byte 0x5 ! column 27 .byte 0x1b! uleb128 0x1b; 27 .byte 0x9 ! fixed advance PC, increment view to 1 .uahalf .LLM93-.LLM92 ! from *.LLM92 to *.LLM93 The last line is from dwarf2out.c (output_one_line_info_table) using dw2_asm_output_delta, which has a fat comment about targets that cannot compute the difference between symbols in different sections. Adding -gno-variable-location-views to the compilation makes it succeed. Rainer The last line is from
[Bug c++/84289] warning : variabile unitialized, emit right check only with O(1,2,3) optimisation level (in try/catch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84289 --- Comment #2 from claudio daffra --- yes, but people expects g++ emit warning , Independent from optimisation level , referring others simlar bug . can you fix ? Il 09 feb 2018 00:09, "manu at gcc dot gnu.org"ha scritto: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84289 > > Manuel López-Ibáñez changed: > >What|Removed |Added > > > Status|UNCONFIRMED |RESOLVED > CC||manu at gcc dot gnu.org > Resolution|--- |DUPLICATE > > --- Comment #1 from Manuel López-Ibáñez --- > The try-catch creates: > > # n_1 = PHI > # .MEM_2 = PHI <.MEM_4(3), .MEM_12(9)> > _15 = n_1; > > and PHI is only handled with optimization. > > *** This bug has been marked as a duplicate of bug 43361 *** > > -- > You are receiving this mail because: > You reported the bug.
[Bug c++/84263] [8 Regression] ICE in lookup_page_table_entry at gcc/ggc-page.c:646 on valid C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84263 David Malcolm changed: What|Removed |Added Keywords||patch CC||dmalcolm at gcc dot gnu.org --- Comment #3 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00435.html
[Bug c++/83372] ICE in GC within gt_ggc_mx building Mir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83372 --- Comment #16 from David Malcolm --- (In reply to David Malcolm from comment #15) > Alan: are you able to test Nathan's bug to see if it fixes the issue for you? ^^^ patch, I meant to say
[Bug c++/83372] ICE in GC within gt_ggc_mx building Mir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83372 David Malcolm changed: What|Removed |Added Keywords||GC, ice-on-valid-code, ||needs-bisection, ||needs-reduction, patch Status|ASSIGNED|WAITING See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84263 Summary|Compiler segfaults building |ICE in GC within |Mir |gt_ggc_mx building Mir --- Comment #15 from David Malcolm --- I tried Nathan's patch from here: [PR c++/84263] GC ICE with decltype https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00435.html With the patch, it successfully compiles the file. Without the patch: it ICEs, with corrupted memory in the buffer pointer to by "checks": (gdb) p *x $10 = {value = 0x7ffe4295b7e0, checks = 0x7ffe425ca6c0, qualifying_scope = 0x0} (gdb) p *x->checks $14 = {m_vecpfx = {m_alloc = 1919901535, m_using_auto_storage = 0, m_num = 1953709151}, m_vecdata = {{binfo = 0x75665f73693a3a64, decl = 0x763c6e6f6974636e, diag_decl = 0x26262a282064696f, loc = 1803036713}}} (gdb) call debug(x->value) full-name "class std::unique_ptr" needs-constructor needs-destructor X() has-type-conversion X(constX&) this=(X&) n_parents=0 use_template=1 interface-unknown (gdb) call inform (x->location, "token is here") /builddir/build/BUILD/mir-5500595810c28c150a3bd9edf19b392c2aeab932/src/server/frontend/wayland/wayland_connector.cpp:980:17: note: token is here Hence it looks like this is a duplicate of PR c++/84263 (but hard to be sure without properly reducing it). Nathan: does this look like a duplicate to you? Any ideas on how to reduce the reproducer? (the ~1hr time to hit the bug when forcing GC is making this awkward). Alan: are you able to test Nathan's bug to see if it fixes the issue for you? Thanks.
[Bug target/84077] [7/8 Regression] Likely wrong code with `__builtin_expect()` on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84077 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #14 from Jakub Jelinek --- Besides inline asm barriers another option is volatile {float,double} vars in certain spots (to ensure rounding to {float,double} where required). And again, you don't need to do anything if FLT_EVAL_METHOD is 0, or for double computations also if FLT_EVAL_METHOD is 1.
[Bug target/84077] [7/8 Regression] Likely wrong code with `__builtin_expect()` on i686-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84077 --- Comment #13 from Flössie --- Thanks for the thorough analysis. We'll discuss in our team how to cope with it. Best regards, Flössie