[Bug target/69421] [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6888 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69421 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-22 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Markus Trippelsdorf --- operators/mx-inlines.cc: In function ‘void mx_inline_eq(size_t, bool*, const X*, Y) [with X = std::complex; Y = std::complex]’: operators/mx-inlines.cc:115:203: error: type mismatch in conditional expression vector(16) unsigned char vector(2) vector(16) unsigned char vect_patt_2.1423_120 = VEC_COND_EXPR ; operators/mx-inlines.cc:115:203: internal compiler error: verify_gimple failed 0xd3726c verify_gimple_in_cfg(function*, bool) ../../gcc/gcc/tree-cfg.c:5125 0xc2765a execute_function_todo ../../gcc/gcc/passes.c:1958 0xc27fcb execute_todo ../../gcc/gcc/passes.c:2010 Please submit a full bug report, Reducing...
[Bug tree-optimization/69426] [6 Regression] ICE: verify_ssa failed (error: missing definition) w/ -O2 (and above) -ftree-parallelize-loops=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69426 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-22 Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from vries at gcc dot gnu.org --- Confirmed. Disappears with fix for PR69110, but may not be a duplicate. Does also occur with transform_to_exit_first_loop instead of transform_to_exit_first_loop_at.
[Bug fortran/68442] ICE on kind specification, depending on ordering of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68442 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #8 from Jerry DeLisle --- Taking this one.
[Bug fortran/69397] ICE on missing subprogram in generic interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69397 --- Comment #4 from Jerry DeLisle --- See patch attached to PR68442, attachment 37430
[Bug tree-optimization/68692] [6 Regression][graphite] ice: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68692 --- Comment #7 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-cvs/2016-01/msg00645.html : Author: spop Date: Thu Jan 21 02:14:01 2016 New Revision: 232659 URL: https://gcc.gnu.org/viewcvs?rev=232659&root=gcc&view=rev Log: fix pr68692: reinstantiate the copy of internal parameters Adding a testcase and reverting this patch: [PATCH] remove parameter_rename_map This map was used in the transition to the new scop detection: with the new scop detection, we do not need this map anymore. * graphite-isl-ast-to-gimple.c (gcc_expression_from_isl_ast_expr_id): Remove use of parameter_rename_map. (copy_def): Remove. (copy_internal_parameters): Remove. (graphite_regenerate_ast_isl): Remove call to copy_internal_parameters. * sese.c (new_sese_info): Do not initialize parameter_rename_map. (free_sese_info): Do not free parameter_rename_map. (set_rename): Do not use parameter_rename_map. (rename_uses): Update call to set_rename. (graphite_copy_stmts_from_block): Do not use parameter_rename_map. * sese.h (parameter_rename_map_t): Remove. (struct sese_info_t): Remove field parameter_rename_map. Added: trunk/gcc/testsuite/gfortran.dg/graphite/pr68692.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-isl-ast-to-gimple.c trunk/gcc/sese.c trunk/gcc/sese.h
[Bug fortran/68442] ICE on kind specification, depending on ordering of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68442 --- Comment #7 from Jerry DeLisle --- Created attachment 37430 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37430&action=edit Patch for testing (In reply to Dominique d'Humieres from comment #6) > > Are you getting this error with a clean tree? I get an ICE with a clean tree > at r232669. Note this is the kind of error I was expecting. Let me clarify. I am working a patch attempting to define an error message that will work. There are two different test cases that trigger the ICE. One is the test case in PR69397, the other is one of the two cases in this PR.
[Bug rtl-optimization/54472] ICE (spill_failure): unable to find a register to spill in class 'AREG' with -O -fschedule-insns -fselective-scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54472 Andrey Belevantsev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Andrey Belevantsev --- 4.7 is not maintained anymore.
[Bug rtl-optimization/69307] [4.9/5/6 Regression] wrong code with -O2 -fselective-scheduling @ armv7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69307 Andrey Belevantsev changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |abel at gcc dot gnu.org
[Bug c++/69428] [6 Regression] Many libstdc++ failures on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69428 Andrew Pinski changed: What|Removed |Added Component|libstdc++ |c++ --- Comment #2 from Andrew Pinski --- Note this also might be caused by a patch that I have there too but I doubt it.
[Bug libstdc++/69428] [6 Regression] Many libstdc++ failures on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69428 --- Comment #1 from Andrew Pinski --- It looks like a miscompiling. I am testing to see if revision 232711 caused it.
[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932 --- Comment #24 from Ramana Radhakrishnan --- *** Bug 67295 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/64164] [4.9/5/6 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 Bug 64164 depends on bug 67295, which changed state. Bug 67295 Summary: [ARM][6 Regression] FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67295 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/67295] [ARM][6 Regression] FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67295 Ramana Radhakrishnan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Ramana Radhakrishnan --- (In reply to Jeffrey A. Law from comment #9) > Should we consolidate 67295, 65932 & 67714 with one being the canonical bug > for this problem and close the others as duplicates? Yes I agree - based on Kyrill's assessment. *** This bug has been marked as a duplicate of bug 65932 ***
[Bug middle-end/67295] [ARM][6 Regression] FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67295 --- Comment #10 from Ramana Radhakrishnan --- (In reply to Jakub Jelinek from comment #7) > At the RTL level, it would be nice if REE optimized away at least the > redundant zero extension, thus change: > cmp r1, #0 > rev16ne r0, r0 > uxthne r0, r0 > .L2: > sxthr0, r0 > b foos16 > to > cmp r1, #0 > rev16ne r0, r0 > .L2: > sxthr0, r0 > b foos16 > but it seems ARM doesn't enable REE at all. Or should some other pass > handle that case? Isn't REE supposed to be enabled for targets that do automatic extension when writing to a smaller part of a bigger register ? I thought REE existed to remove unnecessary zero extends in those sort of situations on ports that had the above mentioned feature. The only reason why we may want to enable REE on ARM is probably to remove extra extensions after implicit extensions done by a load, but I thought that was handled else where with LOAD_EXTEND_OP in combine. That is what I can see based on a fresh skim of the comments at the top of REE to refresh my memory. Am I missing something ?
[Bug libstdc++/69428] [6 Regression] Many libstdc++ failures on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69428 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.0 Summary|Many libstdc++ failures on |[6 Regression] Many |aarch64-linux-gnu |libstdc++ failures on ||aarch64-linux-gnu
[Bug libstdc++/69428] New: Many libstdc++ failures on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69428 Bug ID: 69428 Summary: Many libstdc++ failures on aarch64-linux-gnu Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: aarch64-linux-gnu -LAST_UPDATED: Thu Jan 21 20:05:07 UTC 2016 (revision 232699) +LAST_UPDATED: Fri Jan 22 01:21:50 UTC 2016 (revision 232716) This showed up just in the last few hours between the above versions.
[Bug target/63304] Aarch64 pc-relative load offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304 Ramana Radhakrishnan changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #45 from Ramana Radhakrishnan --- I no longer have plans to fix this in the GCC 5 branch.
[Bug target/69427] gcc-4.9.3 compilation for the cross target m68k-rtems4.11 in i686-Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69427 --- Comment #4 from Satish --- (In reply to Andrew Pinski from comment #1) > Which version of G++ are you using at the beginning? g++ also 4.9.3 $g++ --version g++ (GCC) 4.9.3
[Bug target/63304] Aarch64 pc-relative load offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304 --- Comment #44 from Ramana Radhakrishnan --- (In reply to Christophe Lyon from comment #39) > We have backported r227748, 229160 and 229161 to our linaro-gcc-5 branch, > and we got a bug report from the kernel team. Sorry about the breakage. > > Indeed, when the kernel is configured with CONFIG_ARM64_ERRATUM_843419, the > support for relocations R_AARCH64_ADR_PREL_PG_HI21 and > R_AARCH64_ADR_PREL_PG_HI21_NC is removed from the kernel to avoid loading > objects with possibly offending sequences. In this case the kernel is built > with > -mcmodel=large. > > With these backports, these relocations are generated again by default. The reason for the code generation to be in this form , is to store literal pools in rodata and not have any data in the code segment at all. Now when these need to be addressed that far away, addressing them with adrp / load is reasonable as you are thinking of a text + rodata segment to be > 4GB before this fails. In an ideal world this would be implemented by the 4 insn mov / movk sequence to construct the literal address, however those relocations are not likely to be supported by the kernel loader (or rather I haven't checked). > > Adding -mpc-relative-literal-loads to the kernel Makefile in > arch/arm64/Makefile does fix the build, but since this option is not > supported by GCC if it does not contain these backports (and the compiler > aborts with an error), it's not obvious how to modify the Makefile to decide > when to use this option. (In reply to Christophe Lyon from comment #43) > Indeed, that seems safer. > However, reading http://www.spinics.net/lists/arm-kernel/msg445346.html > there is a comment saying: > -- > Note that the kernel itself must be linked with a version of ld > which fixes potentially affected ADRP instructions through the > use of veneers > --- > > But I don't know how this is enforced. With kernel modules, there's no way the linker fix can be used as kernel modules are simply put just object files. When I did the work, I had forgotten about the erratum and the repercussions on kernel modules. Thus -mpc-relative-literal-loads is quite a reasonable workaround to the problem. > > Or... change GCC's -mfix-cortex-a53-843419 to change the default for > -mpc-relative-literal-loads and add -mfix-cortex-a53-843419 to the kernel > Makefile. That's probably not that bad an idea as a short term workaround for GCC 6.
[Bug target/69427] gcc-4.9.3 compilation for the cross target m68k-rtems4.11 in i686-Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69427 --- Comment #3 from Satish --- @Andrew Pinski I was using 4.9.3 $ gcc --version gcc (GCC) 4.9.3 (In reply to Andrew Pinski from comment #1) > Which version of G++ are you using at the beginning?
[Bug target/69427] gcc-4.9.3 compilation for the cross target m68k-rtems4.11 in i686-Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69427 --- Comment #2 from Satish --- @Andrew Pinski I was using 4.9.3 $ gcc --version gcc (GCC) 4.9.3
[Bug target/69427] gcc-4.9.3 compilation for the cross target m68k-rtems4.11 in i686-Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69427 Andrew Pinski changed: What|Removed |Added Keywords||build Target||m68k-rtems4.11 Component|c++ |target Host||i686-Cygwin Build||i686-Cygwin Severity|blocker |normal --- Comment #1 from Andrew Pinski --- Which version of G++ are you using at the beginning?
[Bug c++/69427] New: gcc-4.9.3 compilation for the cross target m68k-rtems4.11 in i686-Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69427 Bug ID: 69427 Summary: gcc-4.9.3 compilation for the cross target m68k-rtems4.11 in i686-Cygwin Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kaluvalapalli.satish24 at gmail dot com Target Milestone: --- Created attachment 37429 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37429&action=edit gcc-4.9.3 compilation for the cross target m68k-rtems4.11 in i686-Cygwin I am trying to make a RTEMS tool chain for the m68k target, while compilation of gcc we are facing below errors.Before 2 months we are able to compile same version tar file of gcc-4.9.3.tar.gz but now we are facing below errors with the same compiler. Could you please help me to solve. g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite- strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/cygdrive/d/DevelopmentTools/Build/build- gcc493-rtems411_X_freebsd92_cygwin/tools/gcc-4.9.3/gcc -I/cygdrive/d/DevelopmentTools/Build/build- gcc493-rtems411_X_freebsd92_cygwin/tools/gcc-4.9.3/gcc/build -I/cygdrive/d/DevelopmentTools/Build/build- gcc493-rtems411_X_freebsd92_cygwin/tools/gcc-4.9.3/gcc/../include -I/cygdrive/d/DevelopmentTools/Build/build- gcc493-rtems411_X_freebsd92_cygwin/tools/gcc-4.9.3/gcc/../libcpp/include \ -o build/genpreds.o /cygdrive/d/DevelopmentTools/Build/build- gcc493-rtems411_X_freebsd92_cygwin/tools/gcc-4.9.3/gcc/genpreds.c In file included from /cygdrive/d/DevelopmentTools/Build/build- gcc493-rtems411_X_freebsd92_cygwin/tools/gcc-4.9.3/gcc/system.h:1064:0, from /cygdrive/d/DevelopmentTools/Build/build- gcc493-rtems411_X_freebsd92_cygwin/tools/gcc-4.9.3/gcc/genpreds.c:24: /cygdrive/d/DevelopmentTools/Build/build- gcc493-rtems411_X_freebsd92_cygwin/tools/gcc-4.9.3/gcc/hwint.h:16:39: error: division by zero in #if #define HOST_BITS_PER_LONG (CHAR_BIT * SIZEOF_LONG) ^ /cygdrive/d/DevelopmentTools/Build/build- gcc493-rtems411_X_freebsd92_cygwin/tools/gcc-4.9.3/gcc/hwint.h:60:35: note: in expansion of macro ‘HOST_BITS_PER_LONG’ # define HOST_BITS_PER_WIDE_INT HOST_BITS_PER_LONG ^ /cygdrive/d/DevelopmentTools/Build/build- gcc493-rtems411_X_freebsd92_cygwin/tools/gcc-4.9.3/gcc/real.h:71:25: note: in expansion of macro ‘HOST_BITS_PER_WIDE_INT’ (REAL_VALUE_TYPE_SIZE/HOST_BITS_PER_WIDE_INT \ ^ /cygdrive/d/DevelopmentTools/Build/build- gcc493-rtems411_X_freebsd92_cygwin/tools/gcc-4.9.3/gcc/real.h:85:5: note: in expansion of macro ‘REAL_WIDTH’ #if REAL_WIDTH == 1 ^ /cygdrive/d/DevelopmentTools/Build/build- gcc493-rtems411_X_freebsd92_cygwin/tools/gcc-4.9.3/gcc/hwint.h:16:39: error: division by zero in #if #define HOST_BITS_PER_LONG (CHAR_BIT * SIZEOF_LONG) ^ /cygdrive/d/DevelopmentTools/Build/build- gcc493-rtems411_X_freebsd92_cygwin/tools/gcc-4.9.3/gcc/hwint.h:60:35: note: in expansion of macro ‘HOST_BITS_PER_LONG’ # define HOST_BITS_PER_WIDE_INT HOST_BITS_PER_LONG ^ /cygdrive/d/DevelopmentTools/Build/build- gcc493-rtems411_X_freebsd92_cygwin/tools/gcc-4.9.3/gcc/real.h:72:28: note: in expansion of macro ‘HOST_BITS_PER_WIDE_INT’ + (REAL_VALUE_TYPE_SIZE%HOST_BITS_PER_WIDE_INT ? 1 : 0)) /* round up */ ^ /cygdrive/d/DevelopmentTools/Build/build- gcc493-rtems411_X_freebsd92_cygwin/tools/gcc-4.9.3/gcc/real.h:85:5: note: in expansion of macro ‘REAL_WIDTH’ #if REAL_WIDTH == 1 ^ /cygdrive/d/DevelopmentTools/Build/build- gcc493-rtems411_X_freebsd92_cygwin/tools/gcc-4.9.3/gcc/hwint.h:16:39: error: division by zero in #if #define HOST_BITS_PER_LONG (CHAR_BIT * SIZEOF_LONG) ^ /cygdrive/d/DevelopmentTools/Build/build- gcc493-rtems411_X_freebsd92_cygwin/tools/gcc-4.9.3/gcc/hwint.h:60:35: note: in expansion of macro ‘HOST_BITS_PER_LONG’ # define HOST_BITS_PER_WIDE_INT HOST_BITS_PER_LONG ^ /cygdrive/d/DevelopmentTools/Build/build- gcc493-rtems411_X_freebsd92_cygwin/tools/gcc-4.9.3/gcc/real.h:71:25: note: in expansion of macro ‘HOST_BITS_PER_WIDE_INT’ (REAL_VALUE_TYPE_SIZE/HOST_BITS_PER_WIDE_INT \ ^ /cygdrive/d/DevelopmentTools/Build/build- gcc493-rtems411_X_freebsd92_cygwin/tools/gcc-4.9.3/gcc/real.h:88:6: note: in expansion of macro ‘REAL_WIDTH’ # if REAL_WIDTH == 2 ^ /cygdrive/d/DevelopmentTools/Build/build- gcc493-rtems411_X_freebs
[Bug testsuite/69406] FAIL: 17_intro/headers/c++2011/linkage.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69406 --- Comment #4 from Thomas Preud'homme --- It does indeed. Thanks
[Bug tree-optimization/69426] New: [6 Regression] ICE: verify_ssa failed (error: missing definition) w/ -O2 (and above) -ftree-parallelize-loops=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69426
Bug ID: 69426
Summary: [6 Regression] ICE: verify_ssa failed (error: missing
definition) w/ -O2 (and above)
-ftree-parallelize-loops=2
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: vries at gcc dot gnu.org
Target Milestone: ---
At least gcc-6.0.0-alpha20160110 and gcc-6.0.0-alpha20160117 snapshots ICE when
compiling the following reduced snippet w/ -O2 (-O3, -Ofast)
-ftree-parallelize-loops=2:
int iq;
void
mr(void)
{
unsigned int i8;
for (i8 = 0; i8 != 1; i8 += 3) {
void *f0[] = { f0 };
int hv;
for (; hv < 1; ++hv)
iq = 0;
}
++iq;
}
% gcc-6.0.0-alpha20160117 -c -O2 -ftree-parallelize-loops=2 nmrq2xcy.c -Wall
-Wextra -Wpedantic
nmrq2xcy.c: In function 'mr':
nmrq2xcy.c:4:1: error: missing definition
mr(void)
^~
for SSA_NAME: .MEM_11 in statement:
.MEM_2 = PHI <.MEM_11(17), .MEM_7(D)(15)>
PHI argument
.MEM_11
for PHI node
.MEM_2 = PHI <.MEM_11(17), .MEM_7(D)(15)>
nmrq2xcy.c:4:1: internal compiler error: verify_ssa failed
[Bug testsuite/67489] FAIL: gcc.target/powerpc/p8vector-builtin-8.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67489 Bill Schmidt changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Bill Schmidt --- Fixed.
[Bug testsuite/67489] FAIL: gcc.target/powerpc/p8vector-builtin-8.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67489
--- Comment #2 from Bill Schmidt ---
Author: wschmidt
Date: Fri Jan 22 03:01:27 2016
New Revision: 232717
URL: https://gcc.gnu.org/viewcvs?rev=232717&root=gcc&view=rev
Log:
2016-01-21 Bill Schmidt
PR testsuite/67489
* gcc.target/powerpc/p8vector-builtin-8.c: Remove { target int128
} from dg-do compile directive, and instead add {
dg-require-effective-target int128 }.
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/p8vector-builtin-8.c
[Bug c++/69379] [6 Regression] ICE in fold_convert_loc, at fold-const.c:2366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69379 --- Comment #11 from Martin Michlmayr --- Created attachment 37428 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37428&action=edit Preprocessed source
[Bug c++/69379] [6 Regression] ICE in fold_convert_loc, at fold-const.c:2366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69379 --- Comment #10 from Martin Michlmayr --- (In reply to Martin Michlmayr from comment #9) > Ok, I'll re-start the delta run. I'm sorry, but this isn't making any progress so I cannot offer a reduced testcase. However, I'll attach preprocessed source from another package that fails with this ICE. $ g++-6 -c -Wformat PushButton.pypp.ii
[Bug lto/69393] [6 Regression] ICE in dwarf2out_finish, at dwarf2out.c:27175 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69393 --- Comment #7 from Martin Michlmayr --- I should note that I don't see this with -r -nostdlib, as described in the wiki. (sid)604:tbm@dl580gen9-02: ~/a] g++-6 -r -nostdlib STAR.ii Genome.ii Stats.ii genomeGenerate.ii -g -O2 -fopenmp -flto -flto (sid)605:tbm@dl580gen9-02: ~/a] g++-6 -o STAR -flto -flto -g -O2 -fopenmp STAR.ii Genome.ii Stats.ii genomeGenerate.ii lto1: internal compiler error: in dwarf2out_finish, at dwarf2out.c:27175 0x6a2e00 dwarf2out_finish ../../src/gcc/dwarf2out.c:27175 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. This is with 6.0.0 20160117 on x86_64-linux-gnu.
[Bug lto/69393] [6 Regression] ICE in dwarf2out_finish, at dwarf2out.c:27175 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69393 --- Comment #6 from Martin Michlmayr --- Created attachment 37427 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37427&action=edit Preprocessed source
[Bug lto/69393] [6 Regression] ICE in dwarf2out_finish, at dwarf2out.c:27175 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69393 --- Comment #5 from Martin Michlmayr --- Created attachment 37426 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37426&action=edit Preprocessed source
[Bug lto/69393] [6 Regression] ICE in dwarf2out_finish, at dwarf2out.c:27175 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69393 --- Comment #4 from Martin Michlmayr --- Created attachment 37425 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37425&action=edit Preprocessed source
[Bug lto/69393] [6 Regression] ICE in dwarf2out_finish, at dwarf2out.c:27175 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69393 --- Comment #3 from Martin Michlmayr --- Created attachment 37424 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37424&action=edit Preprocessed source
[Bug lto/69393] [6 Regression] ICE in dwarf2out_finish, at dwarf2out.c:27175 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69393 --- Comment #2 from Martin Michlmayr --- Ok, I can reproduce this issue like this: g++-6 -o STAR -flto -flto -g -O2 -fopenmp STAR.ii Genome.ii Stats.ii genomeGenerate.ii I've attached the preprocessed source.
[Bug middle-end/19986] [meta-bug] fold missing optimizations (compared to RTL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19986 Bug 19986 depends on bug 25530, which changed state. Bug 25530 Summary: (unsigned / 2)*2 is not changed into unsigned &~1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25530 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25530 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #4 from Andrew Pinski --- Fixed.
[Bug middle-end/31531] A microoptimization of isnegative of signed integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31531 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #14 from Andrew Pinski --- My patch needs to be re-written to use match.pd instead.
[Bug tree-optimization/52409] ((~a)|(~b)) is not simplified at the tree level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52409 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #2 from Andrew Pinski --- Fixed for at least 6, it might have been fixed in GCC 5.
[Bug c++/63550] Multiple definition errors occur only with -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63550 torvald at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-22 CC||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from torvald at gcc dot gnu.org --- Confirmed with r232693. std::vector's constructor isn't considered transaction_safe, but see the attached test case. I'm not sure making the clones weak is the right approach; the clones should probably mirror whatever is done for the original functions.
[Bug c++/63550] Multiple definition errors occur only with -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63550 --- Comment #3 from torvald at gcc dot gnu.org --- Created attachment 37423 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37423&action=edit Test case part 3/3
[Bug c++/63550] Multiple definition errors occur only with -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63550 --- Comment #2 from torvald at gcc dot gnu.org --- Created attachment 37422 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37422&action=edit Test case part 2/3
[Bug c++/63550] Multiple definition errors occur only with -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63550 --- Comment #1 from torvald at gcc dot gnu.org --- Created attachment 37421 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37421&action=edit Test case part 1/3
[Bug c/69425] __atomic_load should diagnose const output parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69425 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Martin Sebor --- Agreed. This is a duplicate of bug 69404 I coincidentally just raised last night. *** This bug has been marked as a duplicate of bug 69404 ***
[Bug c/69404] atomic builtins accept incompatible pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69404 Martin Sebor changed: What|Removed |Added CC||eric at efcs dot ca --- Comment #6 from Martin Sebor --- *** Bug 69425 has been marked as a duplicate of this bug. ***
[Bug testsuite/69371] UNRESOLVED: special_functions/18_riemann_zeta/check_value.cc compilation failed to produce executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69371 --- Comment #5 from Ed Smith-Rowland <3dw4rd at verizon dot net> --- On 01/20/2016 11:46 PM, thopre01 at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69371 > > --- Comment #4 from Thomas Preud'homme --- > Doh, I should have caught that earlier. The bug can be seen in: > > % grep -c dg-option special_functions/18_riemann_zeta/check_value.cc > 3 > > Using dg-additional-option for the timeout solves the issue. Maybe the patch > could also remove the redundant timeout adjustment in the testcase? > I'll take care of that. My deja-fu is wobbly...
[Bug c/69405] [6 Regression] ICE in c_tree_printer on an invalid __atomic_fetch_add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69405 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug c++/63472] transaction_atomic within while loop causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63472 torvald at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #8 from torvald at gcc dot gnu.org --- Seems to be the same problem as bug 60908. *** This bug has been marked as a duplicate of bug 60908 ***
[Bug c++/60908] compiler bug related to trans-mem.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60908 torvald at gcc dot gnu.org changed: What|Removed |Added CC||spear at cse dot lehigh.edu --- Comment #5 from torvald at gcc dot gnu.org --- *** Bug 63472 has been marked as a duplicate of this bug. ***
[Bug target/54670] ICE in extract_insn, at recog.c:2125
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54670 Martin Sebor changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Martin Sebor --- Closing. Please reopen if the problem comes back.
[Bug tree-optimization/69110] [4.9/5/6 Regression] execution failure in gcc.c-torture/execute/doloop-{1,2}.c with -ftree-parallelize-loops=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69110 --- Comment #18 from vries at gcc dot gnu.org --- (In reply to vries from comment #17) > (In reply to vries from comment #15) > > https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00801.html: > > ... > > > During testing however, I ran into two testsuite regressions: > > > > > > 1. > > > > > > -PASS: gfortran.dg/graphite/pr39516.f -O (test for excess errors) > > > +FAIL: gfortran.dg/graphite/pr39516.f -O (internal compiler error) > > > +FAIL: gfortran.dg/graphite/pr39516.f -O (test for excess errors) > > > > > I've managed to reproduce the pr39516.f failure in C, and modified the > test-case to trigger without the fix for this PR. Filed as PR69292. PR69292 no longer reprodudes. Same for the pr39516.f failure in combination with approved patch.
[Bug c++/60908] compiler bug related to trans-mem.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60908 --- Comment #4 from torvald at gcc dot gnu.org --- Still happens with r232693.
[Bug libitm/69018] libitm/testsuite/libitm.c++/c++.exp: libstdc++ include paths don't work if tests set options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69018 torvald at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-21 Ever confirmed|0 |1 --- Comment #2 from torvald at gcc dot gnu.org --- Downgraded because this is not user-visible and we have a work-around.
[Bug tree-optimization/69292] [6 Regression][graphite] ICE with -floop-nest-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69292 --- Comment #5 from vries at gcc dot gnu.org --- ICE no longer occurs at r232659, the fix for pr68692. Can this PR be marked duplicate of pr68692?
[Bug c/69405] [6 Regression] ICE in c_tree_printer on an invalid __atomic_fetch_add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69405 --- Comment #3 from Martin Sebor --- Author: msebor Date: Thu Jan 21 23:19:05 2016 New Revision: 232713 URL: https://gcc.gnu.org/viewcvs?rev=232713&root=gcc&view=rev Log: PR c/69405 - [6 Regression] ICE in c_tree_printer on an invalid __atomic_fetch_add gcc/testsuite/ChangeLog: 2016-01-20 Martin Sebor PR c/69405 * gcc.dg/sync-fetch.c: New test. gcc/c-family/ChangeLog: 2016-01-20 Martin Sebor PR c/69405 * c-common.c (sync_resolve_size): Avoid printing diagnostic about an incompatible argument when the argument isn't a valid tree node. Added: trunk/gcc/testsuite/gcc.dg/sync-fetch.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/57348] [TM] ICE for transaction expression in gimplify_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57348 torvald at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from torvald at gcc dot gnu.org --- Works with r232693.
[Bug tree-optimization/68976] [6 Regression] ICE w/ -O2 (and above) -fgraphite-identity (or -floop-nest-optimize)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68976 --- Comment #15 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-cvs/2016-01/msg00644.html : Author: spop Date: Thu Jan 21 02:13:52 2016 New Revision: 232658 URL: https://gcc.gnu.org/viewcvs?rev=232658&root=gcc&view=rev Log: fix PR68976: only add loop close phi for names defined in loop * graphite-isl-ast-to-gimple.c: Fix comment. * graphite-scop-detection.c (defined_in_loop_p): New. (canonicalize_loop_closed_ssa): Do not add close phi nodes for SSA names defined in loop. gcc/testsuite * gcc.dg/graphite/pr68976.c: New test. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr68976.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-isl-ast-to-gimple.c trunk/gcc/graphite-scop-detection.c trunk/gcc/testsuite/ChangeLog
[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655 --- Comment #17 from Roger Orr --- As you say, there seems to be another, unrelated, problem with the current trunk and cygwin. However, I have now successfully built gcc version 232300 under cygwin with this patch. Unfortunately, if I try to compile and execute the test program: $ g++ -O2 -fno-inline pr66655.C pr66655_1.cc $ ./a.exe it produces a segmentation fault, just as reported with the mingw build. So it does seem that cygwin needs the problem fixed, just like mingw, but that the orginal fix has other, unfortunate, consequences.
[Bug other/69424] libcc1/findcomp.cc:21:18: fatal error: string: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69424 Andrew Pinski changed: What|Removed |Added Severity|blocker |normal --- Comment #1 from Andrew Pinski --- What target? Also how did you configure GCC? Are you building in a different directory than the source one? If not why not?
[Bug c/69425] New: __atomic_load should diagnose const output parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69425
Bug ID: 69425
Summary: __atomic_load should diagnose const output parameter
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eric at efcs dot ca
Target Milestone: ---
The __atomic_load builtin takes a pointer to an output parameter. Obviously the
output parameter cannot point to a const object. Unfortunatly GCC doesn't
diagnose this case at compile time and this makes it much harder for users to
find their bug.
The reproducer is contrived, but I ran into this while writing generic code.
#include
int main() {
const int source = 4;
const int dest = 0;
__atomic_load(&source, &dest, __ATOMIC_RELAXED); // Should emit
-Wdiscards-qualifiers
assert(dest == 4); // FAILS! 'dest' is still 0.
}
[Bug c/57855] passing unsafe function as transaction_safe function pointer does not generate error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57855
torvald at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-01-21
Component|libitm |c
Version|unknown |6.0
Ever confirmed|0 |1
--- Comment #3 from torvald at gcc dot gnu.org ---
I can confirm that this still happens with r232693 if the test program is
compiled as a C program; a warning is produced, but there is no error.
However, if compiling the reproducer as a C++ program, an error is returned, as
required by the TM TS:
pr57855.c:28:14: error: invalid conversion from ‘void (*)(const char*, int,
const char*, int, const void*)’ to ‘ADD_STAT {aka void (*)(const char*, int,
const char*, int, const void*) transaction_safe}’ [-fpermissive]
bar(my_func);
I'm not sure whether the initial TM specification required an error, but I
think it's better to keep this open given that ISO C++ SG5 people are working
on / interested in a variant of the TM TS for C (ie, so that we don't forget
about it). Eventually, I would suppose that we phase out support for the old
TM specification. Therefore, I've also reduced the priority of this and
associated this with the C frontend.
[Bug other/69424] New: libcc1/findcomp.cc:21:18: fatal error: string: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69424 Bug ID: 69424 Summary: libcc1/findcomp.cc:21:18: fatal error: string: No such file or directory Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: ext73 at wp dot pl Target Milestone: --- Until the release of gcc-5-20160105 everything worked properly. By contrast, the version of gcc-5-20160112 I am not able to install gcc. An error appears: mkdir -p -- /opt/gcc-5.3.1/lib/../lib64 mkdir -p -- /opt/gcc-5.3.1/include/libiberty make[3]: Wejście do katalogu `/tmp/gcc-5-20160119/build-gcc/libiberty/testsuite' make[3]: Nie ma nic do zrobienia w `install'. make[3]: Opuszczenie katalogu `/tmp/gcc-5-20160119/build-gcc/libiberty/testsuite' make[2]: Opuszczenie katalogu `/tmp/gcc-5-20160119/build-gcc/libiberty' make[2]: Wejście do katalogu `/tmp/gcc-5-20160119/build-gcc/libcc1' make install-am make[3]: Wejście do katalogu `/tmp/gcc-5-20160119/build-gcc/libcc1' /bin/bash ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I/tmp/gcc-5-20160119/./libcc1 -I /tmp/gcc-5-20160119/./libcc1/../include -I /tmp/gcc-5-20160119/./libcc1/../libgcc -I ../gcc -I/tmp/gcc-5-20160119/./libcc1/../gcc -I /tmp/gcc-5-20160119/./libcc1/../gcc/c -I /tmp/gcc-5-20160119/./libcc1/../gcc/c-family -I /tmp/gcc-5-20160119/./libcc1/../libcpp/include -W -Wall -fvisibility=hidden -g -O2 -MT findcomp.lo -MD -MP -MF .deps/findcomp.Tpo -c -o findcomp.lo /tmp/gcc-5-20160119/./libcc1/findcomp.cc libtool: compile: g++ -DHAVE_CONFIG_H -I. -I/tmp/gcc-5-20160119/./libcc1 -I /tmp/gcc-5-20160119/./libcc1/../include -I /tmp/gcc-5-20160119/./libcc1/../libgcc -I ../gcc -I/tmp/gcc-5-20160119/./libcc1/../gcc -I /tmp/gcc-5-20160119/./libcc1/../gcc/c -I /tmp/gcc-5-20160119/./libcc1/../gcc/c-family -I /tmp/gcc-5-20160119/./libcc1/../libcpp/include -W -Wall -fvisibility=hidden -g -O2 -MT findcomp.lo -MD -MP -MF .deps/findcomp.Tpo -c /tmp/gcc-5-20160119/./libcc1/findcomp.cc -fPIC -DPIC -o .libs/findcomp.o /tmp/gcc-5-20160119/./libcc1/findcomp.cc:21:18: fatal error: string: No such file or directory compilation terminated. make[3]: *** [findcomp.lo] Błąd 1 make[3]: Opuszczenie katalogu `/tmp/gcc-5-20160119/build-gcc/libcc1' make[2]: *** [install] Błąd 2 make[2]: Opuszczenie katalogu `/tmp/gcc-5-20160119/build-gcc/libcc1' make[1]: *** [install-libcc1] Błąd 2 make[1]: Opuszczenie katalogu `/tmp/gcc-5-20160119/build-gcc' make: *** [install] Błąd 2 Of course objdir is different than srcdir - what you see. When configured with the option: --disable-libcc1 builds and installs properly. Regards Tomasz Miś
[Bug middle-end/67295] [ARM][6 Regression] FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67295 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #9 from Jeffrey A. Law --- Should we consolidate 67295, 65932 & 67714 with one being the canonical bug for this problem and close the others as duplicates?
[Bug target/69252] [4.9/5 Regression] gcc.dg/vect/vect-iv-9.c FAILs with -Os -fmodulo-sched -fmodulo-sched-allow-regmoves -fsched-pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69252 --- Comment #15 from Jeffrey A. Law --- Author: law Date: Thu Jan 21 22:58:29 2016 New Revision: 232712 URL: https://gcc.gnu.org/viewcvs?rev=232712&root=gcc&view=rev Log: PR target/69252 * modulo-sched.c (optimize_sc): Allow branch-scheduling to add a new first stage. PR target/69252 * gcc.target/powerpc/pr69252.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr69252.c Modified: trunk/gcc/ChangeLog trunk/gcc/modulo-sched.c trunk/gcc/testsuite/ChangeLog
[Bug target/69252] [4.9/5 Regression] gcc.dg/vect/vect-iv-9.c FAILs with -Os -fmodulo-sched -fmodulo-sched-allow-regmoves -fsched-pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69252 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Summary|[4.9/5/6 Regression]|[4.9/5 Regression] |gcc.dg/vect/vect-iv-9.c |gcc.dg/vect/vect-iv-9.c |FAILs with -Os |FAILs with -Os |-fmodulo-sched |-fmodulo-sched |-fmodulo-sched-allow-regmov |-fmodulo-sched-allow-regmov |es -fsched-pressure |es -fsched-pressure --- Comment #14 from Jeffrey A. Law --- I committed the patch & testcase. Removing gcc6 regression marker.
[Bug c++/69290] [6 Regression] ICE on invalid initialization of a flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69290 Martin Sebor changed: What|Removed |Added Summary|[6 Regression] g++ ICE |[6 Regression] ICE on |(segfault) on |invalid initialization of a |x86_64-linux-gnu|flexible array member --- Comment #2 from Martin Sebor --- Patch posted for review: https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01685.html
[Bug fortran/69423] New: Invalid optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69423 Bug ID: 69423 Summary: Invalid optimization Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- Using latest svn master branch, the follow code produces wrong results when compiled with -O1 and higher optimizations: program tester character(LEN=:), allocatable :: S S= test(2) contains function test(alen) character(LEN=:), allocatable :: test integer alen, i do i = alen, 1, -1 test = 'test' exit end do !This line prints nothing when compiled with -O1 and higher print *, test end function test end program tester
[Bug fortran/69418] [5/6 Regression] ICE: tree check: expected record_type ... in gfc_class_vptr_get, at fortran/trans-expr.c:149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69418 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.4
[Bug target/46393] [4.9/5/6 Regression] m68k code size regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46393 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.9.4
[Bug other/69006] [6 Regression] Extraneous newline emitted between error messages in GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69006 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic, patch URL||https://gcc.gnu.org/ml/gcc- ||patches/2016-01/msg00782.ht ||ml Target Milestone|--- |6.0
[Bug target/68273] [5/6 Regression] Wrong code on mips/mipsel with -fipa-sra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273 --- Comment #10 from Jeffrey A. Law --- I understand everything you're saying Richi. Note however that the MIPS backend explicitly wants to align things based on the object's alignment -- even scalars passed in registers: /* Advance to an even register if the argument is doubleword-aligned. */ if (doubleword_aligned_p) info->reg_offset += info->reg_offset & 1; Which can be tracked back to this commit: commit 26bcab5a0015a5304899649081fd676996b8 Author: rsandifo Date: Sat Sep 25 07:42:43 2004 + * config/mips/mips.h (struct mips_args): Clarify comments. * config/mips/mips.c (struct mips_arg_info): Likewise. (mips_arg_info): Don't allow fpr_p to affect the register or stack alignment. Remove o64 silliness. (function_arg): Deal with the o32 float,float case specially. Which is the end of a slew of fixes to this code -- enough that tracking down the original source of the aligned register stuff is painful at best. I'm nowhere near comfortable to take this further -- my MIPS knowledge is old and limited more to the ISA than the nitty gritty details of argument passing. One could argue that this kind of alignment hackery is fundamentally broken and can't be baked into the ABI. But the reality is this code has been in GCC for well over a decade, so it has effectively become part of the ABI. Anyway, leaving to the MIPS maintainers to sort out. It ought to be dramatically easier at this point.
[Bug fortran/69422] New: Unexpected result with allocatable character type component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69422 Bug ID: 69422 Summary: Unexpected result with allocatable character type component Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- With the current svn master branch the following code prints out nothing for 'test result': module funcs implicit none Type T character(LEN=:), allocatable :: source end type T type TPointer Type(T), pointer :: P end type TPointer end module program Test1 use funcs Type(TPointer) :: X allocate(X%P) X%P%Source = 'test string' print *, 'test result = ', X%P%Source end program Test1 This may be a regression from earlier 6.0 commits, but not sure.
[Bug fortran/68442] ICE on kind specification, depending on ordering of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68442 --- Comment #6 from Dominique d'Humieres --- > I am currently getting: > > $ gfc pr68442.f90 > pr68442.f90:10:21: > > character(kind=gkind()) :: x > > Error: Function âgkindâ in initialization expression at (1) must be an > intrinsic function Are you getting this error with a clean tree? I get an ICE with a clean tree at r232669. Note this is the kind of error I was expecting.
[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991 --- Comment #9 from torvald at gcc dot gnu.org --- Still fails with r232693. This seems to be another case of difficult ordering between TM passes and other passes. It makes sense that we don't inline tm_pure because we must not loose that information. always_inline is specified to produce an error when not inlining, but this shouldn't be much of a problem when considering code instrumented for transactions I suppose (can there be a case where lack of inlining causes a correctness problem?). Perhaps it's easiest if we clone the function if we see such a case, so that the solution can be different for TM-instrumented clones and normal code.
[Bug fortran/69418] [5/6 Regression] ICE: tree check: expected record_type ... in gfc_class_vptr_get, at fortran/trans-expr.c:149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69418 --- Comment #3 from Dominique d'Humieres --- > likely r221474 (pr69418). read "likely r221474 (pr59198)".
[Bug tree-optimization/69347] [6 regression] excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69347 --- Comment #14 from Jeffrey A. Law --- Author: law Date: Thu Jan 21 22:21:55 2016 New Revision: 232711 URL: https://gcc.gnu.org/viewcvs?rev=232711&root=gcc&view=rev Log: [PATCH] [PR tree-optimization/69347] Fix memory consumption in threader & minor speed improvement PR middle-end/69347 * tree-ssa-dom.c (dom_opt_dom_walker::thread_across_edge): Avoid useless call to record_temporary_equivalences. * tree-ssa-threadbackward.c (find_jump_threads_backwards): Just allocate 10 slots in the bb_path vector and let it grow as needed. (fsm_find_control_statement_thread_paths): Similarly for the next_path vector. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-dom.c trunk/gcc/tree-ssa-threadbackward.c
[Bug fortran/69418] [5/6 Regression] ICE: tree check: expected record_type ... in gfc_class_vptr_get, at fortran/trans-expr.c:149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69418 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||4.9.3 Keywords||ice-on-valid-code Last reconfirmed||2016-01-21 CC||pault at gcc dot gnu.org, ||vehre at gcc dot gnu.org Ever confirmed|0 |1 Summary|ICE: tree check: expected |[5/6 Regression] ICE: tree |record_type ... in |check: expected record_type |gfc_class_vptr_get, at |... in gfc_class_vptr_get, |fortran/trans-expr.c:149|at fortran/trans-expr.c:149 Known to fail||5.3.0, 6.0 --- Comment #2 from Dominique d'Humieres --- The ICE appeared between revisions 2214164 (2015-03-16, OK) and r221495 (2015-03-18, ICE), likely r221474 (pr69418).
[Bug testsuite/67489] FAIL: gcc.target/powerpc/p8vector-builtin-8.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67489 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-01-21 Ever confirmed|0 |1 --- Comment #1 from Bill Schmidt --- Confirmed.
[Bug fortran/69417] ICE: tree check: expected function_type or method_type, have pointer_type in gimplify_call_expr, at gimplify.c:2467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69417 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-21 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed from 4.8 up to 5.3 with the ICE in aggregate_value_p, at function.c:* and for trunk (6.0) with ICE in gimplify_call_expr, at gimplify.c:*.
[Bug target/69421] [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6888 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69421 --- Comment #3 from Martin Michlmayr --- (In reply to Andrew Pinski from comment #1) > What target is this on? x86_64-linux-gnu
[Bug target/69421] [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6888 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69421 --- Comment #2 from Martin Michlmayr --- Created attachment 37420 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37420&action=edit Preprocessed source
[Bug c++/69392] G++ can't capture 'this' pointer to templated type using init-capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69392 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-01-21 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/69421] [6 Regression] ICE in maybe_legitimize_operand, at optabs.c:6888 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69421 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Component|middle-end |target Target Milestone|--- |6.0 Summary|ICE in |[6 Regression] ICE in |maybe_legitimize_operand, |maybe_legitimize_operand, |at optabs.c:6888 with -O3 |at optabs.c:6888 with -O3 --- Comment #1 from Andrew Pinski --- What target is this on?
[Bug middle-end/69421] New: ICE in maybe_legitimize_operand, at optabs.c:6888 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69421 Bug ID: 69421 Summary: ICE in maybe_legitimize_operand, at optabs.c:6888 with -O3 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: tbm at cyrius dot com Target Milestone: --- This is with 6.0.0 20160117: $ g++-6 -O3 -c octave.ii In file included from array/CMatrix.cc:61:0: operators/mx-inlines.cc: In function 'void mx_inline_eq(size_t, bool*, const X*, Y) [with X = std::complex; Y = std::complex]': operators/mx-inlines.cc:115:295: internal compiler error: in maybe_legitimize_operand, at optabs.c:6888 0x9de99e maybe_legitimize_operand ../../src/gcc/optabs.c:6887 0x9de99e maybe_legitimize_operands(insn_code, unsigned int, unsigned int, expand_operand*) ../../src/gcc/optabs.c:6954 0x9debd9 maybe_gen_insn(insn_code, unsigned int, expand_operand*) ../../src/gcc/optabs.c:6972 0x9e87d8 maybe_expand_insn(insn_code, unsigned int, expand_operand*) ../../src/gcc/optabs.c:7015 0x9e87d8 expand_insn(insn_code, unsigned int, expand_operand*) ../../src/gcc/optabs.c:7046 0x9e8d29 expand_vec_cond_mask_expr(tree_node*, tree_node*, tree_node*, tree_node*, rtx_def*) ../../src/gcc/optabs.c:5557 0x9e8ff4 expand_vec_cond_expr(tree_node*, tree_node*, tree_node*, tree_node*, rtx_def*) ../../src/gcc/optabs.c:5590 0x86f607 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) ../../src/gcc/expr.c:9343 0x86232b expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../src/gcc/expr.c:9562 0x86bdcc expand_expr ../../src/gcc/expr.h:256 0x86bdcc expand_assignment(tree_node*, tree_node*, bool) ../../src/gcc/expr.c:4797 0x78ae7e expand_gimple_stmt_1 ../../src/gcc/cfgexpand.c:3606 0x78ae7e expand_gimple_stmt ../../src/gcc/cfgexpand.c:3702 0x78c97c expand_gimple_basic_block ../../src/gcc/cfgexpand.c:5708 0x7918a6 execute ../../src/gcc/cfgexpand.c:6323 Please submit a full bug report,
[Bug c++/69290] [6 Regression] g++ ICE (segfault) on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69290 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Known to fail||6.0
[Bug lto/68685] LTO build hits ICE in copy_to_mode_reg, at explow.c:595
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68685 --- Comment #2 from Bill Schmidt --- Hm, I can't reproduce this with current trunk. Instead I get a lot of undefined references from /tmp/*.ltrans0.ltrans.o which seems to indicate we've gotten beyond the point of the reported failure. Anton, can you please check your original code with ToT?
[Bug c++/69379] [6 Regression] ICE in fold_convert_loc, at fold-const.c:2366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69379 --- Comment #9 from Martin Michlmayr --- Ok, I'll re-start the delta run.
[Bug target/65501] [5 Regression] v850 ICE at c_register_pragma_1, at c-family/c-pragma.c:1317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65501 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2015-07-31 00:00:00 |2016-01-21 Summary|[5/6 Regression] v850 ICE |[5 Regression] v850 ICE at |at c_register_pragma_1, at |c_register_pragma_1, at |c-family/c-pragma.c:1317|c-family/c-pragma.c:1317 Ever confirmed|0 |1 --- Comment #5 from Jeffrey A. Law --- Fixed on the trunk by the change for 68271. I'm not currently planning to backport to gcc-5.
[Bug fortran/65996] [5/6 Regression] gfortran ICE with -dH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65996 --- Comment #12 from Jerry DeLisle --- Author: jvdelisle Date: Thu Jan 21 21:08:00 2016 New Revision: 232707 URL: https://gcc.gnu.org/viewcvs?rev=232707&root=gcc&view=rev Log: 2016-01-21 Jerry DeLisle PR fortran/65996 * error.c (gfc_error): Save the state of abort_on_error and set it to false for buffered errors to allow normal processing. Restore the state before leaving. 2016-01-21 Jerry DeLisle PR fortran/65996 gfortran.dg/pr65996.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr65996.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/error.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/69376] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69376 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Indeed, that looks like a serious problem. Bet we want to add a anti_range_p bitfield to struct vn_ssa_aux, initialize it and set SSA_NAME_ANTI_RANGE_P from it.
[Bug c++/65656] __builtin_constant_p should always be constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65656 --- Comment #5 from H.J. Lu --- *** Bug 69399 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/69399] [5/6 Regression] wrong code with -O and int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69399 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #8 from H.J. Lu --- Dup. *** This bug has been marked as a duplicate of bug 65656 ***
[Bug c++/68810] [6/7 regression] FAIL: g++.dg/cpp0x/constexpr-reinterpret1.C -- test for errors -- -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68810 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P2 Target Milestone|6.0 |7.0 Summary|[6 regression] FAIL:|[6/7 regression] FAIL: |g++.dg/cpp0x/constexpr-rein |g++.dg/cpp0x/constexpr-rein |terpret1.C -- test for |terpret1.C -- test for |errors -- -m32 |errors -- -m32 --- Comment #13 from Jakub Jelinek --- Testcase adjusted, for GCC 7 we should improve the locus even for the targets where the pointer size is different from int's type.
[Bug target/69416] [6 Regression] Nonsense rtl checking failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416 --- Comment #7 from Wilco --- (In reply to Richard Henderson from comment #5) > Created attachment 37419 [details] > proposed patch > > I'm testing the following, but it does produce correct results > on a spot check of emit-rtl.c:1833. Yes, it looks right now. > We do leave a missed-optimization on the table, in that the > (compare:CC (const_int 29) (const_int 0)) subexpression isn't > optimized. But that's something do addresss in gcc7. We could add patterns to handle some of these special cases, however the tree optimizations should really have removed any redundant comparisons before RTL.
[Bug c++/69116] [4.9/5/6 Regression] compile error when including valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69116 --- Comment #5 from Jason Merrill --- I don't see a compiler bug here. EDG also rejects the reduced testcase, for the same reason.
[Bug tree-optimization/67781] [5 Regression] wrong code generated on big-endian with -O1 -fexpensive-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67781 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Jeffrey A. Law --- Backported to gcc-5 branch as well. Closing.
[Bug lto/69394] [5.3] ICE when linking with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69394 --- Comment #2 from Daniel Starke --- I have tested the same with gcc 4.9.3 to make clear whether this is a regression or not. Sadly I was not able to build the libstdc++ with -flto. Compiling the same program as before did not result in a ICE but did produce a binary which was not exatuable on the target platform. Next I build gcc 5.3.0 again and all used libraries with that compiler. Before I did use some libraries I generated with gcc 5.3.0 on the target platform, not on Linux. So I suspect that the output of the same gcc differs on Windows and Linux even though the same target is built. The result was the same as with gcc 4.9.3. The produced binary was not executable. For information, this was the backtrace: #0 0x00635ef2 in std::type_info::operator== (this=this@entry=0x6cffe8 , arg=...) at ../../../../../src/gcc-5.3.0/libstdc++-v3/libsupc++/tinfo.cc:46 #1 0x005bf0f4 in __cxxabiv1::__si_class_type_info::__do_dyncast (this=0x6cffe8 , src2dst=0, access_path=__cxxabiv1::__class_type_info::__contained_public, dst_type=0x0, obj_ptr=0x3790a0, src_type=0x6e5280 , src_ptr=0x3790a0, result=...) at ../../../../../src/gcc-5.3.0/libstdc++-v3/libsupc++/si_class_type_info.cc:52 #2 0x006a6fdb in __cxxabiv1::__dynamic_cast (src_ptr=0x3790a0, src_type=src_type@entry=0x6e5280 , dst_type=dst_type@entry=0x0, src2dst=src2dst@entry=0) at ../../../../../src/gcc-5.3.0/libstdc++-v3/libsupc++/dyncast.cc:72 #3 0x006a12b0 in std::use_facet > (__loc=...) at /new-gcc/bin64-64/gcc-5.3.0/x86_64-w64-mingw32/libstdc++-v3/include/bits/locale_classes.tcc:139 #4 0x004dfce5 in boost::filesystem::path::codecvt() () #5 0x in ?? () #6 0x0067b727 in std::__cxx11::basic_string, std::allocator >::basic_string(char const*, std::allocator const&) [clone .isra.1100] () #7 0x0022fde0 in ?? () #8 0x004f4ed9 in atexit () #9 0x006b52a0 in (anonymous namespace)::__new_handler () #10 0x0003 in ?? () #11 0x007050f0 in vtable for boost::detail::sp_counted_impl_p > () #12 0x006ab266 in _GLOBAL__sub_I__ZN3pcf6parser6spirit18getInnerInfoStringB5cxx11ERKN5boost6spirit4infoE () #13 0x in ?? () Using the compiled libraries from before gives me the following ICE: lto1: internal compiler error: bytecode stream: expected tag bit_field_ref instead of error_mark Replacing for example the libsqlite3 from the build with the compiler in question gives me the following ICE: In member function 'do_real_get': lto1: internal compiler error: bytecode stream: expected tag real_type instead of error_mark Is there no version tag within the LTO code which detects if the format is compatible in an early stage?
[Bug c++/68810] [6 regression] FAIL: g++.dg/cpp0x/constexpr-reinterpret1.C -- test for errors -- -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68810 --- Comment #12 from Jakub Jelinek --- Author: jakub Date: Thu Jan 21 20:29:33 2016 New Revision: 232705 URL: https://gcc.gnu.org/viewcvs?rev=232705&root=gcc&view=rev Log: PR c++/68810 * g++.dg/cpp0x/constexpr-reinterpret1.C: Fix line number that is expected to generate an error. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-reinterpret1.C
[Bug target/69416] [6 Regression] Nonsense rtl checking failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69416 --- Comment #6 from Wilco --- (In reply to Andrew Pinski from comment #4) > Actually I think the problem is (const_int 8 [0x8]) does that make sense > for CC mode? I don't think it does. It should make sense as a CCmode immediate. It relies on CCmode being treated as an opaque type rather than an integer type. There are checks in several places that block simplifications on CCmode, but I guess there are some missing - it's the first time if_then_else has a CCmode result...
[Bug c++/58601] [meta-bug] alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58601 Bug 58601 depends on bug 64987, which changed state. Bug 64987 Summary: alignas(N) (and __attribute__(__aligned__(N))) ignored on enum specifiers https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64987 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
