[Bug c++/84770] [8 Regression] ICE with parameter pack involving typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84770 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org Target Milestone|--- |8.0
[Bug target/84772] powerpc-spe: Spurious "is used uninitialized" warning, or possibly incorrect codegen for va_arg(long double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84772 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Can't reproduce. $ ./xgcc -B ./ -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: powerpc-e500v2-linux-gnuspe Configured with: ../configure --target powerpc-e500v2-linux-gnuspe --disable-bootstrap --enable-languages=c,c++,fortran : (reconfigured) Thread model: posix gcc version 8.0.1 20180309 (experimental) (GCC) $ ./cc1 -quiet -m32 -O2 -Wall -W pr84772.c -nostdinc -mcpu=8540 $ ./cc1 -quiet -m32 -O2 -Wall -W pr84772.c -nostdinc -mcpu=8548 No warnings at all in either. Nor in 7.3.1: $ ./xgcc -B ./ -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: powerpc-glibc-linux-gnuspe Configured with: ../configure --target powerpc-glibc-linux-gnuspe --disable-bootstrap --enable-languages=c,c++,fortran Thread model: posix gcc version 7.3.1 20180309 (GCC) $ ./cc1 -quiet -O -Wall -W pr84772.c -nostdinc
[Bug tree-optimization/84775] [8 Regression] ICE on valid code at -O3: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.c:709
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84775 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Version|unknown |8.0.1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine.
[Bug c++/84767] [6/7/8 Regression] ICE with pointer to VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84767 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |6.5
[Bug debug/84776] Indefinite compile time w/ var-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84776 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Richard Biener --- Yeah, I guess this one is WONTFIX...
[Bug libstdc++/84773] [7/8 Regression] Cross-compilers do not use aligned_alloc or _aligned_malloc for aligned-new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84773 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.4
[Bug target/84757] [7/8 Regression] Useless MOVs and PUSHes to store results of MUL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84757 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started with r244942. Vlad, can you please have a look? Thanks.
[Bug c++/84729] [6/7/8 Regression] internal compiler error: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84729 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- There is decay_conversion or something similar missing somewhere, trying to convers a FUNCTION_DECL to int type is not going to work. But no idea what exactly and where (if in the build_vec_init caller, or in build_vec_init itself.
[Bug target/84763] [8 regression] ICE in i386_pe_seh_cold_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84763 --- Comment #3 from Eric Botcazou --- Author: ebotcazou Date: Fri Mar 9 09:06:52 2018 New Revision: 258381 URL: https://gcc.gnu.org/viewcvs?rev=258381&root=gcc&view=rev Log: PR target/84763 * config/i386/winnt.c (i386_pe_seh_cold_init): Use small pre-allocation when the function accesses prior frames. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20180309-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/winnt.c trunk/gcc/testsuite/ChangeLog
[Bug target/84763] [8 regression] ICE in i386_pe_seh_cold_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84763 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Eric Botcazou --- Thanks for reporting the problem.
[Bug target/67288] [6/7/8 regression] non optimal simple function (useless additional shift/remove/shift/add)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288 Jakub Jelinek changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #11 from Jakub Jelinek --- But the RTL loop optimizers just notice that the BIV has a step of 16 and divides the expression, I think we can't expect those passes to be able to use combine-like simplifications.81082 Another possibility is, if it is easy to predict what loops would be very likely candidates for doloop if the target supports them force for them in IVOPTS an IV with step of 1 (or -1), rather than some other step (and use that IV solely for the loop condition), plus use a IV with the other step if needed; with the expectation that doloop optimizes such IVs away completely and just uses the initial value for initializing the loop counter.
[Bug tree-optimization/82965] [8 regression] gcc.dg/vect/pr79347.c starts failing after r254379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82965
Paul Hua changed:
What|Removed |Added
CC||paul.hua.gm at gmail dot com
--- Comment #12 from Paul Hua ---
On mips64el target there are same fail for now (r258364).
FAIL: gcc.dg/vect/pr79347.c -mmsa scan-tree-dump-not vect "Invalid sum of "
FAIL: gcc.dg/vect/pr79347.c -flto -ffat-lto-objects -mmsa scan-tree-dump-not
vect "Invalid sum of "
After bisected, it's started with r249872.
cross-compile config with:
../configure MISSING=texinfo MAKEINFO=missing --with-mpc=/opt/cfarm/mpc-latest/
--target=mips64el-linux-gnu --enable-languages=c,c++
build cmd:
build/gcc/cc1 -mel -quiet -dumpbase pr79347.c -mmsa -march=mips64r2 -mabi=64
-mllsc -mips64r2 -mno-shared -auxbase-strip pr79347.s -O2 -version
-fdiagnostics-color=never -fno-diagnostics-show-caret -ftree-vectorize
-fvect-cost-model=unlimited -fno-common -fdump-tree-vect-details
-fdump-tree-vect-all -o pr79347.s -fpreprocessed pr79347.i
cat pr79347.i:
...
short *a;
int c;
void n(void)
{
for (int i = 0; i
[Bug other/82352] [7 Regression] comdat-local function called by void h::i() outside its comdat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82352
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #12 from amker at gcc dot gnu.org ---
(In reply to Martin Liška from comment #11)
> Author: marxin
> Date: Thu Mar 8 08:56:20 2018
> New Revision: 258358
>
> URL: https://gcc.gnu.org/viewcvs?rev=258358&root=gcc&view=rev
> Log:
> Backport r256226
>
> 2018-03-08 Martin Liska
>
> Backport from mainline
> 2018-01-04 Martin Liska
>
> PR ipa/82352
> * ipa-icf.c (sem_function::merge): Do not cross comdat boundary.
> 2018-03-08 Martin Liska
>
> Backport from mainline
> 2018-01-04 Martin Liska
>
> PR ipa/82352
> * g++.dg/ipa/pr82352.C: New test.
>
> Added:
> branches/gcc-6-branch/gcc/testsuite/g++.dg/ipa/pr82352.C
> Modified:
> branches/gcc-6-branch/gcc/ChangeLog
> branches/gcc-6-branch/gcc/ipa-icf.c
> branches/gcc-6-branch/gcc/testsuite/ChangeLog
Hi Martin,
The backported test failed on arm-none-eabi and arm-none-linux-gnueabihf with
below message:
/tmp/build/src/gcc/gcc/testsuite/g++.dg/ipa/pr82352.C:20:30: error: 'operator
new' takes type 'size_t' ('unsigned int') as first parameter [-fpermissive]
[Bug target/67288] [6/7/8 regression] non optimal simple function (useless additional shift/remove/shift/add)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288 --- Comment #12 from amker at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #11) > But the RTL loop optimizers just notice that the BIV has a step of 16 and > divides the expression, I think we can't expect those passes to be able to > use combine-like simplifications.81082 > > Another possibility is, if it is easy to predict what loops would be very > likely candidates for doloop if the target supports them force for them in > IVOPTS an IV with step of 1 (or -1), rather than some other step (and use > that IV solely for the loop condition), plus use a IV with the other step if > needed; with the expectation that doloop optimizes such IVs away completely > and just uses the initial value for initializing the loop counter. Yes, so far we only decrease cost by 1 IIRC if IV can terminate at ZERO. That means, we don't cancel all the IV cost. The issue is we don't model what loop is "how" likely be candidates for doloop on TREE level. A task for targets which support doloop? :) Patch always welcome.
[Bug debug/84404] Several "leb128 operand is an undefined symbol" in go testsuite with latest debug improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84404 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Fri Mar 9 09:58:49 2018 New Revision: 258382 URL: https://gcc.gnu.org/viewcvs?rev=258382&root=gcc&view=rev Log: PR debug/84404 * gcc.dg/graphite/pr84404.c: Only compile on pthread effective targets. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/graphite/pr84404.c
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #18 from Jakub Jelinek --- Any further progress? E.g. when you've taken away all the -mcpu= options but 2, why not take away all the powerpcspe-cpus.def entries but the two, masks for other CPUs, etc. Do those CPUs support Altivec or VSX? If not, then perhaps all of altivec.md and vsx.md can go too, the intrinsic headers, etc. etc.
[Bug testsuite/42414] arbitrary path modification by a sed statement breaks testsuite if testsuite is in the absolute path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42414 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Eric Gallager --- (In reply to Ralf Wildenhues from comment #3) > Fixed in 4.5. So... closing this as FIXED then.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084
--- Comment #19 from Jakub Jelinek ---
Similarly, config.gcc has:
powerpc*-*-*spe*)
cpu_type=powerpcspe
extra_headers="ppc-asm.h altivec.h spe.h ppu_intrinsics.h paired.h
spu2vmx.h vec_types.h si2vmx.h htmintrin.h htmxlintrin.h"
case x$with_cpu in
xpowerpc64|xdefault64|x6[23]0|x970|xG5|xpower[3456789]|xpower6x|xrs64a|xcell|xa2|xe500mc64|xe5500|xe6500)
cpu_is_64bit=yes
;;
esac
extra_options="${extra_options} g.opt fused-madd.opt
powerpcspe/powerpcspe-tables.opt"
;;
Aren't the CPUs 32-bit only? So get rid of the above cpu_is_64bit related
stuff, and replace TARGET_64BIT with 0, simplify all code.
The later:
powerpc*-*-* | rs6000-*-*)
guarded default CPU selection allows one to configure for many CPUs powerpcspe
doesn't support, so guess you need to add a powerpc*-*-*spe) entry before that
and only allow there the CPUs that it supports; drop the _32 and _64 suffixed
variants if it is 32-bit only.
[Bug tree-optimization/84777] New: -Os inhibits all vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84777 Bug ID: 84777 Summary: -Os inhibits all vectorization Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: linux at carewolf dot com Target Milestone: --- Neither the command-line flag -ftree-loop-vectorize nor -fopenmp combined with "#pragma omp simd" works when -Os is active. It seems that it when specified manually vectorization should be work even in -Os mode. I can almost see why -ftree-loop-vectorize wouldn't work, which is why I tried the manual marking of loops to vectorize, but the latter didn't work either. I would suggest documenting this behavior and fix at least vectorizing manually marked loops.
[Bug c++/80452] [DR 1579] incorrect value category deduced for return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80452 --- Comment #8 from Martin Liška --- (In reply to Jonathan Wakely from comment #7) > return std::move(cv); Thanks! Works for me. Thus backport would not be probably needed.
[Bug fortran/84734] [8 Regression] Compiling codes with insane array dimensions gives an ICE after r257971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84734 Dominique d'Humieres changed: What|Removed |Added CC||kargl at gcc dot gnu.org Summary|[8 Regression] Compiling|[8 Regression] Compiling |gfortran.dg/size_kind_(2|3) |codes with insane array |.f90 with |dimensions gives an ICE |-fdefault-integer-8 gives |after r257971 |an ICE | --- Comment #3 from Dominique d'Humieres --- Up to revision r257970 compiling the code in comment 2 gives there errors size_kind_2_db.f90:6:13: integer :: B(huge(1_8)+3_8,2_8) 1 Error: Arithmetic overflow at (1) size_kind_2_db.f90:6:31: integer :: B(huge(1_8)+3_8,2_8) 1 Error: The module or main program array 'b' at (1) must have constant shape Starting at r257971 compiling the same code gives an ICE. The option -fdefault-integer-8 only exposed the bug. I have changed the summary to reflect the actual bug.
[Bug tree-optimization/84777] -Os inhibits all vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84777
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #1 from Richard Biener ---
IIRC the issue is that -Os inhibits most loop-header copying.
Can you provide a testcase that shows the issue please?
Can you check if the following patch fixes things for you?
Index: gcc/tree-ssa-loop-ch.c
===
--- gcc/tree-ssa-loop-ch.c (revision 258380)
+++ gcc/tree-ssa-loop-ch.c (working copy)
@@ -257,8 +257,7 @@ public:
/* opt_pass methods: */
virtual bool gate (function *fun)
{
-return flag_tree_ch != 0
- && (flag_tree_loop_vectorize != 0 ||
fun->has_force_vectorize_loops);
+return flag_tree_loop_vectorize != 0 || fun->has_force_vectorize_loops;
}
/* Just copy headers, no initialization/finalization of loop structures. */
[Bug fortran/82859] derived type character component, array comparison inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82859 --- Comment #3 from Dominique d'Humieres --- > I suspect that patch to PR 70409 fixed this one as well. Confirmed.
[Bug fortran/84778] New: Issue with character arguments of specified length (does not compile)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84778 Bug ID: 84778 Summary: Issue with character arguments of specified length (does not compile) Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: david.applegate at woodplc dot com Target Milestone: --- Pass a character "a" into a subroutine with an additional argument integer "b" which specifies its length. This does not compile if integer "b" is declared after character "a" in the subroutine. See below program test implicit none integer, parameter :: b = 5 character(len=b) :: a a = "hello" write(*,*)a//" from main program" call testsub(a,b) contains subroutine testsub(a,b) ! integer, intent(in) :: b ! if we put declaration of b here instead it compiles ok character(len=b), intent(in) :: a integer, intent(in) :: b write(*,*)a//" from testsub" end subroutine testsub end program test
[Bug fortran/84778] Issue with character arguments of specified length (does not compile)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84778 --- Comment #1 from david.applegate at woodplc dot com --- This bug does not occur in GCC 4.8.2
[Bug tree-optimization/84777] -Os inhibits all vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84777
--- Comment #2 from Richard Biener ---
Hmm, patch can't help. Instead try the following which should make the omp
simd
case work.
Index: gcc/tree-ssa-loop-ch.c
===
--- gcc/tree-ssa-loop-ch.c (revision 258380)
+++ gcc/tree-ssa-loop-ch.c (working copy)
@@ -57,7 +57,8 @@ should_duplicate_loop_header_p (basic_bl
be true, since quite often it is possible to verify that the condition is
satisfied in the first iteration and therefore to eliminate it. Jump
threading handles these cases now. */
- if (optimize_loop_for_size_p (loop))
+ if (optimize_loop_for_size_p (loop)
+ && !loop->force_vectorize)
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file,
[Bug tree-optimization/84777] -Os inhibits all vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84777 --- Comment #3 from Richard Biener --- FDO might also help given important loops should show up as hot.
[Bug target/84763] [8 regression] ICE in i386_pe_seh_cold_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84763 --- Comment #5 from Rainer Emrich --- binutils 2.19.1 is building fine now. Bootstrap and complete testsuite run of r258381 in progress. I will send the results to the gcc-testresults mailing list.
[Bug fortran/84779] New: [6/7/8 Regression] Compiling gfortran.fortran-torture/execute/entry_4.f90 with -O1 or -Os and -fdefault-integer-8 gives an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84779 Bug ID: 84779 Summary: [6/7/8 Regression] Compiling gfortran.fortran-torture/execute/entry_4.f90 with -O1 or -Os and -fdefault-integer-8 gives an ICE Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr Target Milestone: --- Compiling gfortran.fortran-torture/execute/entry_4.f90 with -O1 or -Os and -fdefault-integer-8 gives an ICE for gcc4.9 up to trunk (8.0) during RTL pass: expand /opt/gcc/p_work/gcc/testsuite/gfortran.fortran-torture/execute/entry_4.f90:14:0: logical e2 internal compiler error: in gen_lowpart_general, at rtlhooks.c:63 The test compiles and runs with 4.8.5. Reduced test complex function f2 (a) integer a logical e2 entry e2 (a) if (a .gt. 0) then e2 = a .lt. 46 else f2 = 45 endif end function program entrytest logical e2 complex f2 print *, f2(0) if (f2 (0) .ne. 45) call abort () if (.not. e2 (45)) call abort () end
[Bug fortran/84779] [6/7/8 Regression] Compiling gfortran.fortran-torture/execute/entry_4.f90 with -O1 or -Os and -fdefault-integer-8 gives an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84779 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||4.8.5 Keywords||ice-on-valid-code Last reconfirmed||2018-03-09 Ever confirmed|0 |1 Target Milestone|--- |6.5 Known to fail||4.9.3, 5.5.0, 6.4.0, 7.3.0, ||8.0
[Bug target/67288] [6/7/8 regression] non optimal simple function (useless additional shift/remove/shift/add)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67288 --- Comment #13 from Segher Boessenkool --- This setup code is created *by* the RTL loop optimisers, via iv_number_of_iterations IIRC. Combine cannot get rid of it because it does not know the count cannot be 0 (that is info from a different bb). Yes I think we want some extra hooks so the target can tune how expensive loops are, based on exit condition, if it is the inner loop, etc.
[Bug tree-optimization/84777] -Os inhibits all vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84777 --- Comment #4 from Allan Jensen --- I will try the patch. I just tried -fopt-info-vec-missed and the message reported for every loop was: note: not vectorized: latch block not empty. note: bad loop form.
[Bug tree-optimization/84777] -Os inhibits all vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84777
--- Comment #5 from rguenther at suse dot de ---
On Fri, 9 Mar 2018, linux at carewolf dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84777
>
> --- Comment #4 from Allan Jensen ---
> I will try the patch. I just tried -fopt-info-vec-missed and the message
> reported for every loop was:
>
> note: not vectorized: latch block not empty.
> note: bad loop form.
Yeah, that's the effect for while () / for () style loops that haven't
been transformed to do {} while () style by loop header copying.
[Bug tree-optimization/84777] -Os inhibits all vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84777 --- Comment #6 from Allan Jensen --- Great. Your patch worked with 90% of the marked loops! The remaining report things like this with -fopt-info-vec-missed: note: not vectorized: relevant stmt not supported: idisty.872_437 = (unsigned int) idisty_386; note: bad operation or unsupported loop bound. But the result is already pretty good for -fopenmp with manually marked loops.
[Bug c++/84733] [8 Regression] internal compiler error: Segmentation fault (check_local_shadow())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84733 --- Comment #2 from Nathan Sidwell --- Created attachment 43603 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43603&action=edit A simpler testcase. This triggers the pop_local_binding ICE
[Bug tree-optimization/84777] -Os inhibits all vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84777 --- Comment #7 from rguenther at suse dot de --- On Fri, 9 Mar 2018, linux at carewolf dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84777 > > --- Comment #6 from Allan Jensen --- > Great. Your patch worked with 90% of the marked loops! Good! > The remaining report things like this with -fopt-info-vec-missed: > > note: not vectorized: relevant stmt not supported: idisty.872_437 = (unsigned > int) idisty_386; > note: bad operation or unsupported loop bound. > > But the result is already pretty good for -fopenmp with manually marked loops. So is it any better if you use -O2 rather than -Os? Do you really need -Os? GCCs -O2 isn't as excessive code-size wise as competitors like ICC.
[Bug c++/84733] [8 Regression] internal compiler error: Segmentation fault (check_local_shadow())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84733 --- Comment #3 from Nathan Sidwell --- Author: nathan Date: Fri Mar 9 12:13:55 2018 New Revision: 258383 URL: https://gcc.gnu.org/viewcvs?rev=258383&root=gcc&view=rev Log: [PR c++/84733] ICE in check-local-shadow https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00425.html PR c++/84733 * name-lookup.c (do_pushdecl_with_scope): Only clear current_function_decl when pushing a non-class (i.e. namespace) scope. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c
[Bug c++/84733] [8 Regression] internal compiler error: Segmentation fault (check_local_shadow())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84733 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|nathan at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #4 from Nathan Sidwell --- newer ICE fixed r258383. Older ICE remains.
[Bug c++/84767] [6/7/8 Regression] ICE with pointer to VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84767 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 43604 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43604&action=edit gcc8-pr84767.patch Untested fix.
[Bug rtl-optimization/84780] New: [8 Regression] wrong code aarch64 with -O3 --param=tree-reassoc-width=32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84780 Bug ID: 84780 Summary: [8 Regression] wrong code aarch64 with -O3 --param=tree-reassoc-width=32 Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: aarch64-unknown-linux-gnu Created attachment 43605 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43605&action=edit reduced testcase Output: $ aarch64-unknown-linux-gnu-gcc -O3 --param=tree-reassoc-width=32 testcase.c -static $ ./a.out qemu: uncaught target signal 6 (Aborted) - core dumped Aborted $ aarch64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-258366-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/8.0.1/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu --with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld --with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-258366-checking-yes-rtl-df-extra-aarch64 Thread model: posix gcc version 8.0.1 20180308 (experimental) (GCC) Tested revisions: r258366 - FAIL (PR84748 fix) r258075 - FAIL 7-branch r258055 - OK
[Bug rtl-optimization/84780] [8 Regression] wrong code aarch64 with -O3 --param=tree-reassoc-width=32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84780 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug tree-optimization/84777] -Os inhibits all vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84777 --- Comment #8 from Allan Jensen --- Yes, those I say are missing are compared to -O2. I was investigating this in relation to Qt. We either build these files with -O3, or with -Os for customer that are binary size sensitive. Since some of the image handling routines are quite heavy and have been written for auto-vectorization I was just checking if I could get it to work and the results with your patch are quite good: Normal sizes of qdrawhelper.o with -O3/-O2/-Os: 277704 / 198984 / 168440 With -O2 -ftree-vectorize: 242224 With -O2 -fopenmp: 219536 With -Os -ftree-loop-vectorize: 168440 (no change) With -Os -fopenmp: 177144 (with your patch) So most of the -Os benefit and still many of the central draw loops auto-vectorized. Haven't benchmarked it yet though.
[Bug target/84781] New: [missed optimization] ignore bitmask after movemask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84781
Bug ID: 84781
Summary: [missed optimization] ignore bitmask after movemask
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
Testcase: https://godbolt.org/g/S3tfrL
#include
int f(__m128 a) { return _mm_movemask_ps(a)& 0xf; }
int f(__m128d a) { return _mm_movemask_pd(a)& 0x3; }
int f(__m128i a) { return _mm_movemask_epi8(a) & 0xu; }
int f(__m256 a) { return _mm256_movemask_ps(a) & 0xff; }
int f(__m256d a) { return _mm256_movemask_pd(a) & 0xf; }
In all of these functions, the bitmask is a no-op since the movemask cannot
yield bits in any of the masked-off places. Consequently, the bitwise and
should be dropped.
[Bug tree-optimization/84777] -Os inhibits all vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84777 --- Comment #9 from rguenther at suse dot de --- On Fri, 9 Mar 2018, linux at carewolf dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84777 > > --- Comment #8 from Allan Jensen --- > Yes, those I say are missing are compared to -O2. I was investigating this in > relation to Qt. We either build these files with -O3, or with -Os for customer > that are binary size sensitive. Since some of the image handling routines are > quite heavy and have been written for auto-vectorization I was just checking > if > I could get it to work and the results with your patch are quite good: > > Normal sizes of qdrawhelper.o with -O3/-O2/-Os: > 277704 / 198984 / 168440 > > With -O2 -ftree-vectorize: 242224 > With -O2 -fopenmp: 219536 > With -Os -ftree-loop-vectorize: 168440 (no change) > With -Os -fopenmp: 177144 (with your patch) > > So most of the -Os benefit and still many of the central draw loops > auto-vectorized. That looks indeed good. We have enough infrastructure already to support a #pragma GCC vectorize as well (it was added for Ada) just nobody bothered to add C/C++ support. > Haven't benchmarked it yet though. I will test and post the patch, I think it makes sense.
[Bug tree-optimization/84178] [7/8 Regression] ICE in release_bb_predicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84178 --- Comment #9 from Richard Biener --- Author: rguenth Date: Fri Mar 9 13:29:39 2018 New Revision: 258387 URL: https://gcc.gnu.org/viewcvs?rev=258387&root=gcc&view=rev Log: 2018-03-09 Richard Biener PR tree-optimization/84775 * tree-if-conv.c (add_bb_predicate_gimplified_stmts): Delink immediate uses of predicate stmts and mark them modified. Revert PR tree-optimization/84178 * tree-if-conv.c (combine_blocks): Move insert_gimplified_predicates to caller. (version_loop_for_if_conversion): Delay update_ssa call. (tree_if_conversion): Delay update_ssa until after predicate insertion. * gcc.dg/torture/pr84775.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr84775.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c
[Bug tree-optimization/84775] [8 Regression] ICE on valid code at -O3: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.c:709
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84775 --- Comment #3 from Richard Biener --- Author: rguenth Date: Fri Mar 9 13:29:39 2018 New Revision: 258387 URL: https://gcc.gnu.org/viewcvs?rev=258387&root=gcc&view=rev Log: 2018-03-09 Richard Biener PR tree-optimization/84775 * tree-if-conv.c (add_bb_predicate_gimplified_stmts): Delink immediate uses of predicate stmts and mark them modified. Revert PR tree-optimization/84178 * tree-if-conv.c (combine_blocks): Move insert_gimplified_predicates to caller. (version_loop_for_if_conversion): Delay update_ssa call. (tree_if_conversion): Delay update_ssa until after predicate insertion. * gcc.dg/torture/pr84775.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr84775.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c
[Bug tree-optimization/84178] [7/8 Regression] ICE in release_bb_predicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84178 Bug 84178 depends on bug 84775, which changed state. Bug 84775 Summary: [8 Regression] ICE on valid code at -O3: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.c:709 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84775 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/84775] [8 Regression] ICE on valid code at -O3: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.c:709
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84775 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug c++/84782] New: Rejects a maybe C++ code snippet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84782
Bug ID: 84782
Summary: Rejects a maybe C++ code snippet
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
We reject:
$ cat playback_image_provider.ii
template struct c { static constexpr a d = b; };
template a ac();
template class f {
template () = ac)>
void h(int);
template static c h(...);
public:
typedef decltype(h(0)) i;
};
template struct j : f::i {};
class k {
public:
k(const k &);
void operator=(k &&);
};
class l : k {
using ae = k;
using ae::operator=;
};
template struct m {};
template class n : m::d> {};
class o {
struct G {
G(const G &);
l q;
};
n p;
};
o::G::G(const G &) = default;
$ g++ -c playback_image_provider.ii
playback_image_provider.ii:30:1: note: ‘o::G::G(const o::G&)’ is implicitly
deleted because the default definition would be ill-formed:
o::G::G(const G &) = default;
^
playback_image_provider.ii:30:1: error: use of deleted function ‘l::l(const
l&)’
playback_image_provider.ii:17:7: note: ‘l::l(const l&)’ is implicitly declared
as deleted because ‘l’ declares a move constructor or move assignment operator
class l : k {
^
However clang accepts:
$ clang++ -c playback_image_provider.ii -std=c++11
[Bug rtl-optimization/84780] [8 Regression] wrong code aarch64 with -O3 --param=tree-reassoc-width=32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84780 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-09 CC||ktkachov at gcc dot gnu.org Known to work||7.3.1 Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed
[Bug debug/58150] debug info about definition of enum class not emitted if the declaration was already used in a class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58150 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 43606 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43606&action=edit gcc8-pr58150.patch Untested fix.
[Bug c++/84783] New: Missing _mm256_permutexvar_epi64() intrinsic for AVX512VL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84783 Bug ID: 84783 Summary: Missing _mm256_permutexvar_epi64() intrinsic for AVX512VL Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: carsten.benthin at intel dot com Target Milestone: --- Hi, The _mm256_permutexvar_epi64() intrinsic is missing from the avx512vlintrin.h header file. There's only a _mm256_mask_permutexvar_epi64() and a _mm256_maskz_permutexvar_epi64() variant. Both clang 5.0.x and icc 18.0.x have this intrinsic in the header. Thanks, Carsten
[Bug rtl-optimization/84780] [8 Regression] wrong code aarch64 with -O3 --param=tree-reassoc-width=32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84780 --- Comment #2 from ktkachov at gcc dot gnu.org --- Fails for me with -O2 --param=tree-reassoc-width=4. With -fno-if-conversion it doesn't fail but I don't see what the if-conversion passes do wrong, if anything
[Bug fortran/84784] New: ICEs: verify_gimple failed with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84784 Bug ID: 84784 Summary: ICEs: verify_gimple failed with -fdefault-integer-8 Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr Target Milestone: --- Compiling the following tests with -fdefault-integer-8 gfortran.dg/coarray/sync_3.f90 (with -fcheck=all) gfortran.dg/team_change_1.f90 gfortran.dg/team_number_1.f90 gfortran.dg/goacc/nested-function-1.f90 gfortran.dg/popcnt_poppar_2.F90 (-m64, not supported with -m32) for compilers configured with --enable-checking=yes gives an ICE of the kind /opt/gcc/p_work/gcc/testsuite/gfortran.dg/team_change_1.f90:6:0: use iso_fortran_env, only : team_type Error: mismatching comparison operand types integer(kind=8) integer(kind=4) if (new_team != -1) goto ; else goto ; /opt/gcc/p_work/gcc/testsuite/gfortran.dg/team_change_1.f90:6:0: internal compiler error: verify_gimple failed
[Bug fortran/84784] ICEs: verify_gimple failed with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84784 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-09 Blocks||32770 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770 [Bug 32770] [Meta-bug] -fdefault-integer-8 issues
[Bug c++/84785] New: internal compiler error: unexpected expression ‘I’ of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84785
Bug ID: 84785
Summary: internal compiler error: unexpected expression ‘I’ of
kind template_parm_index
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
template struct A;
template struct B;
template struct in_place_index_t {};
template using enable_if_t = typename B::type;
template using invoke_result_t = typename F::type;
template using type_pack_element = int;
template using type_pack_element_t = type_pack_element<1>;
template struct traits;
class C {
public:
template C(in_place_index_t);
};
template class destructor : C {
using super = C;
using super::super;
}
;
class constructor : destructor> {
using super = destructor;
using super::super;
};
class F : constructor {
using super = constructor;
using super::super;
};
template class copy_constructor : F {
using super = F;
using super::super;
}
;
class D : copy_constructor> {
using super = copy_constructor;
using super::super;
};
class G : D {
using super = D;
using super::super;
};
class H : G {
using super = G;
using super::super;
};
class I : H {
using super = H;
using super::super;
};
template using best_match = invoke_result_t;
class variant {
public:
variant() : impl_(in_place_index_t<0>{}) {}
template ::value,
typename = type_pack_element_t, enable_if_t::value, int>>
variant(Arg &&);
I impl_;
};
struct S {
variant var;
};
int main() { S s; }
$ ./cc1plus.258039 -quiet x.cc
x.cc: In substitution of ‘template > using
type_pack_element_t = type_pack_element<1> [with long int = I]’:
x.cc:54:13: required by substitution of ‘template >::value>::type >
variant::variant(Arg&&) [with Arg = const variant&; long int I = ;
= ; typename B
>::value>::type = ]’
x.cc:62:16: required from here
x.cc:54:13: internal compiler error: unexpected expression ‘I’ of kind
template_parm_index
typename = type_pack_element_t, enable_if_t::value,
int>>
^~~~
0x86a8b4 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:4767
0x86ac7b cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:4826
0x86b832 maybe_constant_value(tree_node*, tree_node*)
../../gcc/cp/constexpr.c:5044
0xa10fe8 convert_nontype_argument
../../gcc/cp/pt.c:6542
0xa15cb9 convert_template_argument
../../gcc/cp/pt.c:7862
0xa17772 coerce_template_parms
../../gcc/cp/pt.c:8324
0xa17d1d coerce_innermost_template_parms
../../gcc/cp/pt.c:8429
0xa4d22b instantiate_alias_template
../../gcc/cp/pt.c:18742
0xa32049 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:13712
0xa23c15 tsubst_template_arg
../../gcc/cp/pt.c:10941
0xa50c18 type_unification_real
../../gcc/cp/pt.c:19851
0xa4e388 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc/cp/pt.c:19039
0x7fd8a0 add_template_candidate_real
../../gcc/cp/call.c:3176
0x7fddf2 add_template_candidate
../../gcc/cp/call.c:3258
0x80641e add_candidates
../../gcc/cp/call.c:5525
0x81668e build_new_method_call_1
../../gcc/cp/call.c:9154
0x817c47 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/cp/call.c:9361
0x969717 locate_fn_flags
../../gcc/cp/method.c:1024
0x96ab13 walk_field_subobs
../../gcc/cp/method.c:1439
0x96ba99 synthesized_method_walk
../../gcc/cp/method.c:1744
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/84785] [8 Regression] internal compiler error: unexpected expression ‘I’ of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84785 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |8.0 Summary|internal compiler error:|[8 Regression] internal |unexpected expression ‘I’ |compiler error: unexpected |of kind template_parm_index |expression ‘I’ of kind ||template_parm_index
[Bug c++/84785] [8 Regression] internal compiler error: unexpected expression ‘I’ of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84785 --- Comment #1 from Marek Polacek --- Started with r258039.
[Bug rtl-optimization/84780] [8 Regression] wrong code aarch64 with -O3 --param=tree-reassoc-width=32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84780 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||segher at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Started with r257644, but haven't analyzed if things go wrong during combine or just it made some latent bug reproduceable.
[Bug target/84772] powerpc-spe: Spurious "is used uninitialized" warning, or possibly incorrect codegen for va_arg(long double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84772 --- Comment #2 from Zack Weinberg --- You don't appear to have the exact same build as me. But there's something fishy going on with that, because as far as I can tell, SVN rev 258338 is a *trunk* revision, not a gcc-7-branch revision. Anyway, I'm gonna attach a .stdarg dump from the compiler that does trigger the problem, maybe comparing that to the .stdarg dump you get will help?
[Bug target/84772] powerpc-spe: Spurious "is used uninitialized" warning, or possibly incorrect codegen for va_arg(long double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84772 --- Comment #3 from Zack Weinberg --- Created attachment 43607 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43607&action=edit -fdump-tree-stdarg output for test case from problem compiler I do not entirely understand how to read this (what do the _123(D) suffixes on everything mean?) but right after there sure does appear to be a read of the variable va_arg_tmp.3, which was introduced by this pass, and which does not appear to have been previously initialized.
[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64089
--- Comment #16 from David Malcolm ---
Author: dmalcolm
Date: Fri Mar 9 15:24:44 2018
New Revision: 258388
URL: https://gcc.gnu.org/viewcvs?rev=258388&root=gcc&view=rev
Log:
jit: use 'configure' to replace hard-coded linker options (PR jit/64089 and PR
jit/84288)
gcc/ChangeLog:
PR jit/64089
PR jit/84288
* Makefile.in (LD_VERSION_SCRIPT_OPTION, LD_SONAME_OPTION): New.
* configure: Regenerate.
* configure.ac ("linker --version-script option"): New.
("linker soname option"): New.
gcc/jit/ChangeLog:
PR jit/64089
PR jit/84288
* Make-lang.in (COMMA): New.
(LIBGCCJIT_VERSION_SCRIPT_OPTION): New.
(LIBGCCJIT_SONAME_OPTION): New.
(jit): Move --version-script and -soname linker options to the
above.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/gcc/jit/ChangeLog
trunk/gcc/jit/Make-lang.in
[Bug jit/84288] Support jit on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84288
--- Comment #5 from David Malcolm ---
Author: dmalcolm
Date: Fri Mar 9 15:24:44 2018
New Revision: 258388
URL: https://gcc.gnu.org/viewcvs?rev=258388&root=gcc&view=rev
Log:
jit: use 'configure' to replace hard-coded linker options (PR jit/64089 and PR
jit/84288)
gcc/ChangeLog:
PR jit/64089
PR jit/84288
* Makefile.in (LD_VERSION_SCRIPT_OPTION, LD_SONAME_OPTION): New.
* configure: Regenerate.
* configure.ac ("linker --version-script option"): New.
("linker soname option"): New.
gcc/jit/ChangeLog:
PR jit/64089
PR jit/84288
* Make-lang.in (COMMA): New.
(LIBGCCJIT_VERSION_SCRIPT_OPTION): New.
(LIBGCCJIT_SONAME_OPTION): New.
(jit): Move --version-script and -soname linker options to the
above.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/configure
trunk/gcc/configure.ac
trunk/gcc/jit/ChangeLog
trunk/gcc/jit/Make-lang.in
[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64089 --- Comment #17 from David Malcolm --- This ought to be fixed in trunk (for gcc 8) by r258388.
[Bug jit/84288] Support jit on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84288 --- Comment #6 from David Malcolm --- I'm not sure if r258388 fixes the linker issue on Solaris, but it should make it much easier to fix; e.g. to apply your patch here: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00835.html (currently reported as untested)
[Bug driver/83193] Help for invalid -march= options from cc1 omits -march=native on x86-64, arm. aarch64, output also inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83193 --- Comment #15 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Fri Mar 9 15:42:10 2018 New Revision: 258389 URL: https://gcc.gnu.org/viewcvs?rev=258389&root=gcc&view=rev Log: [arm] PR target/83193: Do not print arch/cpu hints twice on invalid -march/-mcpu Currently when handling an invalid -march or -mcpu option on a toolchain without an explicit --with-mode configuration and compiling without an explicit -mthumb or -marm the arm specs end up calling arm_target_thumb_only to determine the "thumbness" of the target, which involves parsing the architecture or cpu name. But the functions doing that parsing also emit error messages and hints on invalid arguments. Later when we parse the architecture or cpu string to as part of the canonicalisation process (arm_canon_arch_option) we end up emitting the errors again. The solution in this patch is to silence the errors during the arm_target_thumb_only processing so that they are not emitted twice. arm_canon_arch_option is guaranteed to run as well, so it can emit the errors and hints that it needs. Bootstrapped and tested on arm-none-linux-gnueabihf. Checked that we emit the arch/cpu hints for invalid -march/-mcpu options only once when no "thumbness" options were specified during configuration or invocation. PR target/83193 * common/config/arm/arm-common.c (arm_parse_arch_option_name): Accept complain bool parameter. Only emit errors if it is true. (arm_parse_cpu_option_name): Likewise. (arm_target_thumb_only): Adjust callers of the above. * config/arm/arm-protos.h (arm_parse_cpu_option_name): Adjust prototype to take a default true bool parameter. (arm_parse_arch_option_name): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/common/config/arm/arm-common.c trunk/gcc/config/arm/arm-protos.h
[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64089 --- Comment #18 from Francois-Xavier Coudert --- Thanks David. Do you think this could be backported to the active branches?
[Bug driver/83193] Help for invalid -march= options from cc1 omits -march=native on x86-64, arm. aarch64, output also inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83193 Martin Liška changed: What|Removed |Added Target Milestone|8.0 |9.0
[Bug target/84772] powerpc-spe: Spurious "is used uninitialized" warning, or possibly incorrect codegen for va_arg(long double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84772 --- Comment #4 from Zack Weinberg --- The last actual _change_ in my GCC build is r258315 | denisc | 2018-03-07 04:13:12 -0500 (Wed, 07 Mar 2018) | 9 lines Backport from mainline 2018-02-07 Georg-Johann Lay PR target/84209 * config/avr/avr.h (GENERAL_REGNO_P, GENERAL_REG_P): New macros. * config/avr/avr.md: Only post-reload split REG-REG moves if either register is GENERAL_REG_P.
[Bug target/83712] [6/7/8 Regression] "Unable to find a register to spill" when compiling for thumb1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83712 --- Comment #7 from Vladimir Makarov --- Author: vmakarov Date: Fri Mar 9 16:00:36 2018 New Revision: 258390 URL: https://gcc.gnu.org/viewcvs?rev=258390&root=gcc&view=rev Log: 2018-03-09 Vladimir Makarov PR target/83712 * lra-assigns.c (assign_by_spills): Return a flag of reload assignment failure. Do not process the reload assignment failures. Do not spill other reload pseudos if they has the same reg class. (lra_assign): Add a return arg. Set up from the result of assign_by_spills call. (find_reload_regno_insns, lra_split_hard_reg_for): New functions. * lra-constraints.c (split_reg): Add a new arg. Use it instead of usage_insns if it is not NULL. (spill_hard_reg_in_range): New function. (split_if_necessary, inherit_in_ebb): Pass a new arg to split_reg. * lra-int.h (spill_hard_reg_in_range, lra_split_hard_reg_for): New function prototypes. (lra_assign): Change prototype. * lra.c (lra): Add code to deal with fails by splitting hard reg live ranges. 2018-03-09 Vladimir Makarov PR target/83712 * gcc.target/arm/pr83712.c: New. Added: trunk/gcc/testsuite/gcc.target/arm/pr83712.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-assigns.c trunk/gcc/lra-constraints.c trunk/gcc/lra-int.h trunk/gcc/lra.c trunk/gcc/testsuite/ChangeLog
[Bug target/84786] New: [miscompilation] vunpcklpd accessing xmm16-22 targeting KNL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84786 Bug ID: 84786 Summary: [miscompilation] vunpcklpd accessing xmm16-22 targeting KNL Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kretz at kde dot org Target Milestone: --- I see generated code, such as: 424821:· vpxord %zmm17,%zmm17,%zmm17 424827:· vpxord %zmm18,%zmm18,%zmm18 [...] 424855:· vunpcklpd %xmm17,%xmm0,%xmm1 [...] 424891:· vunpcklpd %xmm18,%xmm1,%xmm1 when compiling with `-O2 -march=knl`. Apparently the `_mm_unpacklo_pd` intrinsic is incorrectly translated to an encoding that allows the upper 16 SIMD registers for the first register. Reducing a test case will take some time.
[Bug fortran/84787] New: ICEs: in decompose, at wide-int.h:933 with -default-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84787 Bug ID: 84787 Summary: ICEs: in decompose, at wide-int.h:933 with -default-integer-8 Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr Target Milestone: --- Compiling the following tests with -fdefault-integer-8 gfortran.dg/coarray/image_status_2.f08 gfortran.dg/coarray_image_status_1.f08 for compilers configured with --enable-checking=yes gives an ICE of the kind /opt/gcc/p_work/gcc/testsuite/gfortran.dg/coarray_image_status_1.f08:9:0: if (image_status(1) /= 0) error stop "image_status(1) should not fail" internal compiler error: in decompose, at wide-int.h:933
[Bug target/84772] powerpc-spe: Spurious "is used uninitialized" warning, or possibly incorrect codegen for va_arg(long double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84772 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-03-09 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Jakub Jelinek --- Created attachment 43608 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43608&action=edit gcc8-pr84772.patch Untested fix.
[Bug fortran/84787] ICEs: in decompose, at wide-int.h:933 with -default-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84787 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-09 Blocks||32770 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770 [Bug 32770] [Meta-bug] -fdefault-integer-8 issues
[Bug target/84772] powerpc-spe: Spurious "is used uninitialized" warning, or possibly incorrect codegen for va_arg(long double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84772 --- Comment #5 from Jakub Jelinek --- Ah, I can actually reproduce it with additional -mlong-double-128, both in 7.3 and on the trunk.
[Bug target/84757] [7/8 Regression] Useless MOVs and PUSHes to store results of MUL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84757 --- Comment #3 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #2) > Started with r244942. Vlad, can you please have a look? Thanks. Sure, I'll look at this. Some analysis will be ready today.
[Bug target/84786] [miscompilation] vunpcklpd accessing xmm16-22 targeting KNL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84786 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Without -mavx512vl the 128/256-bit pseudos should never be allocated in xmm16-31 registers, so I really wonder how this happens. If you don't mind attaching unreduced code (compressed), I can do the reduction myself.
[Bug fortran/81827] Large compile time with derived-type rrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81827 Luke Robison changed: What|Removed |Added CC||robison at arlut dot utexas.edu --- Comment #20 from Luke Robison --- (In reply to Paul Thomas from comment #19) Great to see some progress on this, I've been watching from the shadows since I reported it :-). > There are at least three sources of the recursive code: > (i) The allocate statement. This checks to see if the allocate object and > its allocatable components are allocated and deallocates them if > necessary. I must check if the standard requires this! I do not believe the standard requires any deallocation before an allocate() is executed (and I know from experience that trying to allocate an already-allocated variable generally causes crashes). The closest I see to this case in the standard is Section 6.7.3.2 paragraph 7: "When an intrinsic assignment statement is executed, any noncoarray allocated allocatable subobject of the variable is deallocated before the assignment takes place". Which I interpret as being the "realloc-lhs" feature of F2003 (see 7.2.1.3 para 3), but I don't think that applies to the allocate statement itself. > (ii) The vtable 'final' procedure. This calls any user defined 'final' > procedures first, goes on to do the same for the allocatable components, > and then, after each 'final' call, dealloactes if necessary. > (iii) The vtable 'copy'. This is a deep copy of the object and its > allocatable components. It generates a load of code in consequence. I completely agree for (ii) and (iii). Additionally, there seems to be a similar case (iv), which I just noticed: When an allocate is made with a source=. This can be seen in 6.7.1.3 para 5: "When an object of derived type is created by an ALLOCATE statement, any allocatable ultimate components have an allocation status of unallocated *unless* the SOURCE= specifier appears and the corresponding component of the source-expr is allocated." (emphasis mine). I think this is probably implemented as a call to the vtable 'copy', although it happens on an allocate. > The answer is, yes, these recursive procedures are necessary. I just need > to find some less compile time intensive way of implementing them. With regards to the recursive allocation, it certainly does not need to happen on an allocate statement without a source=* specifier, as seen in the above-quote of 6.7.1.3 para 5, although as you point out there are other times when it would be necessary. I hope I've saved you some time digging through the standard. I used this version in my references: https://j3-fortran.org/doc/year/10/10-007r1.pdf
[Bug rtl-optimization/84780] [8 Regression] wrong code aarch64 with -O3 --param=tree-reassoc-width=32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84780
--- Comment #4 from ktkachov at gcc dot gnu.org ---
A carry-setting instruction gets deleted. Among the disassembly the non-failing
assembly has this:
cmp x13, 0
asr w0, w0, w4
csetw4, ne
sxtwx0, w0
adrpx12, d
sub w4, w7, w4
sxtwx9, w7
add w4, w4, w6
asr x6, x0, 63
cmn x4, x2 // sets the carry flag
asr x1, x9, 63
cincx3, x3, cs // Uses the carry flag
The bad disassembly has this:
cmp x4, 0
adrpx13, d
csetw4, ne
asr x7, x0, 63
sxtwx6, w8
cincx1, x3, cs // use of carry flag, but the setter was eliminated
Combine ends up eliminating the carry-setting instruction:
(insn 55 52 56 2 (set (reg:CC_C 66 cc)
(ne:CC_C (plus:TI (zero_extend:TI (reg:DI 165))
(zero_extend:TI (reg:DI 2 x2 [ h ])))
(zero_extend:TI (plus:DI (reg:DI 165)
(reg:DI 2 x2 [ h ]) "bad.c":23 104
{*adddi3_compareC_cconly}
(nil))
From what I can see in the combine logs:
Trying 55 -> 70:
55:
{cc:CC_C=zero_extend(r165:DI)+zero_extend(x2:DI)!=zero_extend(r165:DI+x2:DI);r167:DI=r165:DI+x2:DI;}
REG_DEAD x2:DI
REG_DEAD r165:DI
70: r178:DI=r167:DI
REG_DEAD r167:DI
After a few failed PARALLEL formation it succeeds twice with:
Successfully matched this instruction:
(set (reg:CC_C 66 cc)
(ne:CC_C (plus:TI (zero_extend:TI (reg:DI 165))
(zero_extend:TI (reg:DI 2 x2 [ h ])))
(zero_extend:TI (plus:DI (reg:DI 165)
(reg:DI 2 x2 [ h ])
Successfully matched this instruction:
(set (reg:DI 178)
(plus:DI (reg:DI 165)
(reg:DI 2 x2 [ h ])))
allowing combination of insns 55 and 70
original costs 0 + 0 = 0
replacement costs 24 + 4 = 28
deferring deletion of insn with uid = 55.
modifying insn i255:
cc:CC_C=zero_extend(r165:DI)+zero_extend(x2:DI)!=zero_extend(r165:DI+x2:DI)
deferring rescan insn with uid = 55.
modifying insn i370: r178:DI=r165:DI+x2:DI
REG_DEAD r165:DI
REG_DEAD x2:DI
deferring rescan insn with uid = 70.
so it seems like it deletes insn 55 but then also modifies it?
[Bug target/84772] powerpc-spe: Spurious "is used uninitialized" warning, or possibly incorrect codegen for va_arg(long double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84772
--- Comment #7 from Zack Weinberg ---
I no longer remember enough about GIMPLE to comment on your actual proposed
fix, but I do have a small nitpick on the test case:
+va_arg (ap, long double); /* { dg-bogus "may be used
uninitialized in this function" } */
I think that needs to be just { dg-bogus "used uninitialized" }, as you might
get either the "may be used initialized" or the "is used uninitialized"
message.
[Bug c++/84724] [7/8 Regression] internal compiler error: in single_succ_edge, at basic-block.h:339 with a declaration of __builtin_trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84724 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Fri Mar 9 18:01:22 2018 New Revision: 258391 URL: https://gcc.gnu.org/viewcvs?rev=258391&root=gcc&view=rev Log: PR c++/84724 * decl.c (duplicate_decls): Don't override __* prefixed builtins except for __[^b]*_chk, instead issue permerror and for -fpermissive also a note and return olddecl. * g++.dg/ext/pr84724.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/pr84724-1.C trunk/gcc/testsuite/g++.dg/ext/pr84724-2.C trunk/gcc/testsuite/g++.dg/ext/pr84724-3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/84724] [7 Regression] internal compiler error: in single_succ_edge, at basic-block.h:339 with a declaration of __builtin_trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84724 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[7/8 Regression] internal |[7 Regression] internal |compiler error: in |compiler error: in |single_succ_edge, at|single_succ_edge, at |basic-block.h:339 with a|basic-block.h:339 with a |declaration of |declaration of |__builtin_trap |__builtin_trap --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/84788] New: Parenthesis changes a constant to non-constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84788
Bug ID: 84788
Summary: Parenthesis changes a constant to non-constant
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tuliom at linux dot vnet.ibm.com
Target Milestone: ---
Reproduced with GCC 8.0.1 rev. 258059:
$ cat test-cxx.cpp
template
class PackedCache {
public:
static const int kValuebits = 7;
static const int kValueMask = 1 << ((kValuebits)-1);
};
$ g++ -c test-cxx.cpp
test-cxx.cpp:5:53: error: non-constant in-class initialization invalid for
static member ‘PackedCache::kValueMask’
static const int kValueMask = 1 << ((kValuebits)-1);
^
test-cxx.cpp:5:53: note: (an out of class initialization is required)
If the parenthesis around kValuebits is removed, the error disappears, i.e.:
static const int kValueMask = 1 << (kValuebits-1);
I can't reproduce this error with GCC 7.
This file used to build with rev. 253122.
I can build the file when using -std=gnu++11.
[Bug fortran/84778] Issue with character arguments of specified length (does not compile)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84778 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-03-09 CC||kargl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to david.applegate from comment #0) > Pass a character "a" into a subroutine with an additional argument integer > "b" which specifies its length. This does not compile if integer "b" is > declared after character "a" in the subroutine. See below > > program test > > implicit none > integer, parameter :: b = 5 > character(len=b) :: a > > a = "hello" > > write(*,*)a//" from main program" > > call testsub(a,b) > > contains > > subroutine testsub(a,b) > > ! integer, intent(in) :: b ! if we put declaration of b here instead > it compiles ok > character(len=b), intent(in) :: a > integer, intent(in) :: b > > write(*,*)a//" from testsub" > > end subroutine testsub > end program test The gfortran gives % gfcx -o z m.f90 m.f90:16:18: character(len=b), intent(in) :: a 1 Error: Scalar INTEGER expression expected at (1) plus a few run on errors. The above error message is correct. The dummy argument 'b' in testsub prevents host associate, so when 'b' is used in the above statement it has no type and the implicit none prevents determining what type to use in the specification statement. F2003 explicitly states A variable in a specification expression shall have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, by the implicit typing rules in effect for the scoping unit, or by host or use association. If a variable in a specification expression is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall confirm the implied type and type parameters.
[Bug fortran/82859] derived type character component, array comparison inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82859 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from kargl at gcc dot gnu.org --- It seems that a path for PR 70409 has fixed this issues. Closing.
[Bug fortran/84734] [8 Regression] Compiling codes with insane array dimensions gives an ICE after r257971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84734 kargl at gcc dot gnu.org changed: What|Removed |Added Known to work|6.4.0, 7.3.0| Severity|normal |minor --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #3) > Up to revision r257970 compiling the code in comment 2 gives there errors > > size_kind_2_db.f90:6:13: > > integer :: B(huge(1_8)+3_8,2_8) > 1 > Error: Arithmetic overflow at (1) > Tracing through gdb shows that error is queued. It simply isn't emitted. Have no idea why. I tried using gfc_error_now() and the error was still not emitted. I'll see if I can find the root cause, but this way down my list of important bugs. I've removed the "known to work" entries as I get failures on FreeBSD.
[Bug target/83789] __builtin_altivec_lvx fails for powerpc for altivec-4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83789 --- Comment #13 from Peter Bergner --- Ok, I have a patch that eliminates the duplicate patterns and greatly simplifies the code that calls these patterns. I'm testing it now.
[Bug fortran/84734] [8 Regression] Compiling codes with insane array dimensions gives an ICE after r257971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84734 --- Comment #5 from Dominique d'Humieres --- > I've removed the "known to work" entries > as I get failures on FreeBSD. What failures? With 6.4.0 or 7.3.0 I get the same errors as with r257970.
[Bug fortran/84734] [8 Regression] Compiling codes with insane array dimensions gives an ICE after r257971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84734 --- Comment #6 from Steve Kargl --- On Fri, Mar 09, 2018 at 06:28:24PM +, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84734 > > --- Comment #5 from Dominique d'Humieres --- > > I've removed the "known to work" entries > > as I get failures on FreeBSD. > > What failures? > > With 6.4.0 or 7.3.0 I get the same errors as with r257970. > On 6, troutmask:sgk[249] gfc6 -o z a.f90 f951: internal compiler error: Segmentation fault 0xa2f27f crash_signal ../../gcc6/gcc/toplev.c:333 0x588edb gfc_zero_size_array ../../gcc6/gcc/fortran/arith.c:1657 0x588edb reduce_binary0 ../../gcc6/gcc/fortran/arith.c:1671 0x588edb eval_intrinsic_f3 ../../gcc6/gcc/fortran/arith.c:1720 0x5baf34 simplify_intrinsic_op ../../gcc6/gcc/fortran/expr.c:1051 0x5baf34 gfc_simplify_expr(gfc_expr*, int) ../../gcc6/gcc/fortran/expr.c:1883 0x5ac1fb variable_decl ../../gcc6/gcc/fortran/decl.c:2276 0x5ac1fb gfc_match_data_decl() ../../gcc6/gcc/fortran/decl.c:4957 0x5fef59 match_word_omp_simd ../../gcc6/gcc/fortran/parse.c:93 0x60274e match_word ../../gcc6/gcc/fortran/parse.c:373 0x60274e decode_statement ../../gcc6/gcc/fortran/parse.c:373 0x60 next_free On 7, gfc7 -o z a.f90 a.f90:2:43: integer, parameter :: b(1_k + huge(1_k)) 1 Error: Explicit shaped array with nonconstant bounds at (1) The error is clearly wrong as (1) it should reduce and (2) the queued error Overflow error is emitted.
[Bug rtl-optimization/84682] [6/7/8 Regression] internal compiler error: Segmentation fault (process_address_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84682 --- Comment #7 from Jeffrey A. Law --- Author: law Date: Fri Mar 9 18:50:56 2018 New Revision: 258393 URL: https://gcc.gnu.org/viewcvs?rev=258393&root=gcc&view=rev Log: PR rtl-optimization/84682 * lra-constraints.c (process_address_1): Check is_address flag for address constraints. (process_alt_operands): Likewise. * lra.c (lra_set_insn_recog_data): Pass asm operand locs to preprocess_constraints. * recog.h (preprocess_constraints): Add oploc parameter. Adjust callers. PR rtl-optimization/84682 * gcc.dg/torture/pr84682-1.c: New. * gcc.dg/torture/pr84682-2.c: New. * gcc.dg/torture/pr84682-3.c: New. Added: trunk/gcc/testsuite/gcc.dg/torture/pr84682-1.c trunk/gcc/testsuite/gcc.dg/torture/pr84682-2.c trunk/gcc/testsuite/gcc.dg/torture/pr84682-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/lra.c trunk/gcc/recog.c trunk/gcc/recog.h trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/84682] [6/7 Regression] internal compiler error: Segmentation fault (process_address_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84682 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Summary|[6/7/8 Regression] internal |[6/7 Regression] internal |compiler error: |compiler error: |Segmentation fault |Segmentation fault |(process_address_1) |(process_address_1) --- Comment #8 from Jeffrey A. Law --- Fixed on trunk so far.
[Bug tree-optimization/84526] [8 Regression] ICE in generic_overlap at gcc/gimple-ssa-warn-restrict.c:927 since r257860
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84526 --- Comment #11 from Jeffrey A. Law --- Author: law Date: Fri Mar 9 19:06:26 2018 New Revision: 258394 URL: https://gcc.gnu.org/viewcvs?rev=258394&root=gcc&view=rev Log: gcc/ChangeLog: PR tree-optimization/84526 * gimple-ssa-warn-restrict.c (builtin_memref::set_base_and_offset): Remove dead code. (builtin_access::generic_overlap): Be prepared to handle non-array base objects. gcc/testsuite/ChangeLog: PR tree-optimization/84526 * gcc.dg/Wrestrict-10.c: New test. * gcc.dg/Wrestrict-11.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Wrestrict-10.c trunk/gcc/testsuite/gcc.dg/Wrestrict-11.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-warn-restrict.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/84526] [8 Regression] ICE in generic_overlap at gcc/gimple-ssa-warn-restrict.c:927 since r257860
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84526 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #12 from Jeffrey A. Law --- Fixed by Martin's patch on the trunk.
[Bug c++/84767] [6/7/8 Regression] ICE with pointer to VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84767 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Mar 9 19:12:29 2018 New Revision: 258395 URL: https://gcc.gnu.org/viewcvs?rev=258395&root=gcc&view=rev Log: PR c++/84767 * tree-inline.c (copy_tree_body_r): For INDIRECT_REF of a remapped decl, use remap_type if we want to use the type. * g++.dg/ext/vla18.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/vla18.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c
[Bug c++/84767] [6/7 Regression] ICE with pointer to VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84767 Jakub Jelinek changed: What|Removed |Added Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with |pointer to VLA |pointer to VLA --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/84785] [8 Regression] internal compiler error: unexpected expression ‘I’ of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84785 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-09 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/84734] [8 Regression] Compiling codes with insane array dimensions gives an ICE after r257971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84734 --- Comment #7 from Dominique d'Humieres --- > On 6, ... If it is after r257972 for gcc7 and r257974 for gcc6, then it does not contradicts the fact that the errors are emitted for 6.4.0 or 7.3.0.
[Bug c++/84789] New: [6/7/8 Regression] ICE with broken variable declaration in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84789
Bug ID: 84789
Summary: [6/7/8 Regression] ICE with broken variable
declaration in template class
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following invalid-code code snippet triggers an ICE since GCC 6.3.0:
struct A
{
typedef int I;
};
template struct B : A {};
template struct C : B
{
B::A::I::I i;
};
bug.cc:10:3: internal compiler error: in resolve_typename_type, at
cp/pt.c:25199
B::A::I::I i;
^~~~
0x64b44a resolve_typename_type(tree_node*, bool)
../../gcc/gcc/cp/pt.c:25199
0x932008 cp_parser_nested_name_specifier_opt
../../gcc/gcc/cp/parser.c:6190
0x931624 cp_parser_id_expression
../../gcc/gcc/cp/parser.c:5702
0x939b0a cp_parser_parse_and_diagnose_invalid_type_name
../../gcc/gcc/cp/parser.c:3452
0x92b507 cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:23525
0x92be2a cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:23374
0x92be2a cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:22516
0x92de89 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:22768
0x92de89 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:16774
0x93b0c6 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:13625
0x93f805 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:27184
0x93fb8c cp_parser_template_declaration_after_parameters
../../gcc/gcc/cp/parser.c:26876
0x94044c cp_parser_explicit_template_declaration
../../gcc/gcc/cp/parser.c:27113
0x94044c cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:27132
0x9457b9 cp_parser_declaration
../../gcc/gcc/cp/parser.c:12729
0x945aa1 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:12656
0x945d94 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4561
0x945d94 c_parse_file()
../../gcc/gcc/cp/parser.c:38995
0xa44906 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1132
Please submit a full bug report, [etc.]
[Bug c/84790] New: Miscompilation for MIPS16 with -fpic and -Os or -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790
Bug ID: 84790
Summary: Miscompilation for MIPS16 with -fpic and -Os or -O2
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mschif...@universe-factory.net
Target Milestone: ---
Created attachment 43609
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43609&action=edit
Reproducer C code
Compiling the following piece of C code:
void ext(void);
struct A {
unsigned v;
};
__attribute__((noinline))
void foo(void) {
ext();
}
__attribute__((noinline))
static void bar(struct A *a) {
if (a)
a->v--;
}
__attribute__((noinline))
static void baz(struct A *a) {
bar(a);
}
void test(struct A *a) {
baz(a);
foo();
baz(a);
}
using the command
mips-openwrt-linux-musl-gcc -Os -mips32r2 -mtune=24kc -mips16 -fpic -Wall
-Wextra -c -o reproducer.o reproducer.c
(current OpenWrt toolchain) generates the following code:
:
0: 2403beqza0,8
2: 9c40lw v0,0(a0)
4: 4affaddiu v0,-1
6: dc40sw v0,0(a0)
8: e8a0jrc ra
a: 6500nop
000c :
c: f000 6a00 li v0,0
c: R_MIPS16_HI16_gp_disp
10: f000 0b00 la v1,10
10: R_MIPS16_LO16 _gp_disp
14: f400 3240 sll v0,16
18: e269adduv0,v1
1a: 64c4save32,ra
1c: 659amovegp,v0
1e: d204sw v0,16(sp)
20: 675cmovev0,gp
22: f000 9a40 lw v0,0(v0)
22: R_MIPS16_GOT16 bar
26: f000 4a00 addiu v0,0
26: R_MIPS16_LO16 bar
2a: ea40jalrv0
2c: 653amovet9,v0
2e: 6444restore 32,ra
30: e8a0jrc ra
32: 6500nop
0034 :
34: f000 6a00 li v0,0
34: R_MIPS16_HI16 _gp_disp
38: f000 0b00 la v1,38
38: R_MIPS16_LO16 _gp_disp
3c: f400 3240 sll v0,16
40: e269adduv0,v1
42: 64c4save32,ra
44: 659amovegp,v0
46: d204sw v0,16(sp)
48: 675cmovev0,gp
4a: f000 9a40 lw v0,0(v0)
4a: R_MIPS16_CALL16 ext
4e: ea40jalrv0
50: 653amovet9,v0
52: 6444restore 32,ra
54: e8a0jrc ra
56: 6500nop
0058 :
58: f000 6a00 li v0,0
58: R_MIPS16_HI16 _gp_disp
5c: f000 0b00 la v1,5c
5c: R_MIPS16_LO16 _gp_disp
60: f400 3240 sll v0,16
64: e269adduv0,v1
66: 659amovegp,v0
68: 677cmovev1,gp
6a: 64f5save40,ra,s0-s1
6c: f000 9b00 lw s0,0(v1)
6c: R_MIPS16_GOT16 baz
70: d204sw v0,16(sp)
72: f000 4800 addiu s0,0
72: R_MIPS16_LO16 baz
76: 6538movet9,s0
78: e840jalrs0
7a: 6724moves1,a0
7c: 9604lw a2,16(sp)
7e: f000 9b60 lw v1,0(v1)
7e: R_MIPS16_CALL16 foo
82: 659emovegp,a2
84: eb40jalrv1
86: 653bmovet9,v1
88: 6791movea0,s1
8a: e840jalrs0
8c: 6538movet9,s0
8e: 6475restore 40,ra,s0-s1
90: e8a0jrc ra
92: 6500nop
94: 6500nop
96: 6500nop
98: 6500nop
9a: 6500nop
9c: 6500nop
9e: 6500nop
This is incorrect: The GOT lookup for foo at 7e assumes that v1 still contains
the gp value set at 68, even though it is not valid anymore after the baz call
at 78.
We noticed this issue as it started to affect real software with GCC 7, but for
this reproducer code, GCC 5.4 and 5.5 produce identical code, so it is not a
regression per se.
Version: mips-openwrt-linux-musl-gcc -v
Reading specs from
/home/neoraider/Devel/OpenWrt/openwrt/staging_dir/toolchain-mips_24kc_gcc-7.3.0_musl/lib/gcc/mips-openwrt-linux-musl/7.3.0/specs
COLLECT_GCC=/home/neoraider/Devel/OpenWrt/openwrt/staging_dir/toolchain-mips_24kc_gcc-7.3.0_musl/bin/mips-openwrt-linux-musl-gcc
COLLECT_LTO_WRAPPER=/home/neoraider/Devel/OpenWrt/openwrt/staging_dir/toolchain-mips_24kc_gcc-7.3.0_musl
[Bug c++/84791] New: ICE with broken OpenMP reduction clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84791
Bug ID: 84791
Summary: ICE with broken OpenMP reduction clause
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code, openmp
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following invalid code snippet (compiled with "-fopenmp") triggers an
ICE since GCC 4.9.0 (when OpenMP 4.0 was implemented):
==
typedef int I;
template void foo()
{
I i;
#pragma omp parallel reduction (I::I: i)
;
}
template void foo<0>();
==
bug.cc: In function 'void foo()':
bug.cc:6:35: error: 'I' is not a class, namespace, or enumeration
#pragma omp parallel reduction (I::I: i)
^
bug.cc: In instantiation of 'void foo() [with int = 0]':
bug.cc:10:22: required from here
bug.cc:6:11: internal compiler error: in tsubst_omp_clauses, at cp/pt.c:15664
#pragma omp parallel reduction (I::I: i)
^~~
0x643d33 tsubst_omp_clauses
../../gcc/gcc/cp/pt.c:15664
0x96d9ba tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16654
0x96d4e4 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16190
0x96aecf tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16471
0x96a168 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:16175
0x96a168 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:23540
0x98eb4b instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:23656
0x8b632b c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:4721
Please submit a full bug report, [etc.]
