[Bug tree-optimization/71824] [6/7 Regression] ICE when compiling libiberty with Graphite loop optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71824 --- Comment #11 from Richard Biener --- Author: rguenth Date: Wed Feb 1 08:02:50 2017 New Revision: 245081 URL: https://gcc.gnu.org/viewcvs?rev=245081&root=gcc&view=rev Log: 2017-02-01 Richard Biener PR tree-optimization/71824 * graphite-scop-detection.c (scop_detection::build_scop_breadth): Verify the loops are valid in the merged SESE region. (scop_detection::can_represent_loop_1): Check analyzing the evolution of the number of iterations in the region succeeds. * gcc.dg/graphite/pr71824.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr71824.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-scop-detection.c trunk/gcc/testsuite/ChangeLog
[Bug debug/70578] internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70578 --- Comment #4 from ishikawa,chiaki --- I found that the following simplified command line causes ICE while the next command line where I have removed "-fno-exception" does not cause ICE even though I still keep -gdwarf-output. Hope this may shed some light on the issue. command line and output ICE. /usr/bin/g++-6 -std=gnu++11 -o uvectr64.o -c-gsplit-dwarf -DNDEBUG=1 -DTRIMMED=1 -DU_COMMON_IMPLEMENTATION -DLOCALE_SNAME=92 -DUCONFIG_NO_BREAK_ITERATION -DUCONFIG_NO_TRANSLITERATION -DUCONFIG_NO_REGULAR_EXPRESSIONS -DUCONFIG_NO_LEGACY_CONVERSION -DU_USING_ICU_NAMESPACE=0 -DU_NO_DEFAULT_INCLUDE_UTF_HEADERS=1 -DU_CHARSET_IS_UTF8 -MD -MP -MF -Wall -Wc++11-compat -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 -fno-strict-aliasing -fno-rtti -fno-exceptions -pthread -g3 -Og uvectr64.ii /new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/intl/icu/source/common/uvectr64.cpp:213:3: internal compiler error: in output_index_string, at dwarf2out.c:25635 U_NAMESPACE_END ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Command line without ICE. /usr/bin/g++-6 -std=gnu++11 -o uvectr64.o -c-gsplit-dwarf -DNDEBUG=1 -DTRIMMED=1 -DU_COMMON_IMPLEMENTATION -DLOCALE_SNAME=92 -DUCONFIG_NO_BREAK_ITERATION -DUCONFIG_NO_TRANSLITERATION -DUCONFIG_NO_REGULAR_EXPRESSIONS -DUCONFIG_NO_LEGACY_CONVERSION -DU_USING_ICU_NAMESPACE=0 -DU_NO_DEFAULT_INCLUDE_UTF_HEADERS=1 -DU_CHARSET_IS_UTF8 -MD -MP -MF -Wall -Wc++11-compat -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 -fno-strict-aliasing -fno-rtti -pthread -g3 -Og uvectr64.ii (Not sure though, if the object is correct or not.) TIA
[Bug debug/70578] internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70578 --- Comment #5 from ishikawa,chiaki --- I have found that g++-5 can compile this without ICE. So this is a regression in gcc-6. The version that worked is: g++-5 -v Using built-in specs. COLLECT_GCC=g++-5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 5.4.1-4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.4.1 20161202 (Debian 5.4.1-4) ishikawa@debian-vbox-ci:/tmp$
[Bug ada/79309] incorrectly bounded calls to strncat in adaint.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79309 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-01 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou --- > The following patch fixes the problem: Thanks, but I don't think that we want the %.*s for portability reasons, so a simple sprintf with an enlarged buffer (e.g. 256 bytes) will do.
[Bug ada/79309] incorrectly bounded calls to strncat in adaint.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79309
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
I think it would be better to do:
--- adaint.c2017-01-12 22:28:59.293871830 +0100
+++ adaint.c2017-02-01 09:18:47.027598963 +0100
@@ -3396,14 +3396,16 @@ void __gnat_killprocesstree (int pid, in
{
if ((d->d_type & DT_DIR) == DT_DIR)
{
- char statfile[64] = { 0 };
+ char statfile[64];
int _pid, _ppid;
/* read /proc//stat */
- strncpy (statfile, "/proc/", sizeof(statfile));
- strncat (statfile, d->d_name, sizeof(statfile));
- strncat (statfile, "/stat", sizeof(statfile));
+ if (strlen (d->d_name) > sizeof (statfile) - sizeof ("/proc//stat"))
+ continue;
+ strcpy (statfile, "/proc/");
+ strcat (statfile, d->d_name);
+ strcat (statfile, "/stat");
FILE *fd = fopen (statfile, "r");
You don't want to truncate the buffer in the middle or something in the
hypothetical case something goes wrong, the above is readable and gcc is able
to optimize it into more efficient code that is less readable (i.e. 3 memcpy
calls), using the value of previously computed strlen.
Also note the useless clearing of the whole buffer before it is overwritten.
[Bug go/79281] gccgo: Binaries using goroutines crash on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281 --- Comment #6 from John Paul Adrian Glaubitz --- On gcc-7, we actually can't build when enabling the Go frontend: libtool: compile: /<>/build/./gcc/xgcc -B/<>/build/./gcc/ -B/usr/m68k-linux-gnu/bin/ -B/usr/m68k-linux-gnu/lib/ -isystem /usr/m68k-linux-gnu/include -isystem /usr/m68k-linux-gnu/sys-include -isystem /<>/build/sys-include -DHAVE_CONFIG_H -I. -I../../../src/libgfortran -iquote../../../src/libgfortran/io -I../../../src/libgfortran/../gcc -I../../../src/libgfortran/../gcc/config -I../.././gcc -I../../../src/libgfortran/../libgcc -I../libgcc -I../../../src/libgfortran/../libbacktrace -I../libbacktrace -I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -MT minloc1_16_r4.lo -MD -MP -MF .deps/minloc1_16_r4.Tpo -c ../../../src/libgfortran/generated/minloc1_16_r4.c -o minloc1_16_r4.o >/dev/null 2>&1 go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:2002 mmap: Permission denied Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Makefile:3338: recipe for target 'runtime/internal/sys.lo' failed But first it would be great to get the gcc-6 issue resolved since it will be the default compiler until gcc-7 actually gets released.
[Bug ada/79309] incorrectly bounded calls to strncat in adaint.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79309 --- Comment #4 from Eric Botcazou --- > I think it would be better to do: Yes, this works for me.
[Bug target/79197] [5/6/7 Regression] ICE in extract_insn in gcc/recog.c:2311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79197 --- Comment #9 from Jakub Jelinek --- (In reply to Michael Meissner from comment #8) > I agree the expander should call gpc_reg_operand and not reg_operand. This > is due to the fact that on PowerPCs with separate floating point registers, > SFmode is represented internally as DFmode when it is in the floating > point/vector registers (i.e. my change on January 4th, 2017). I evidently > missed the expander. The gpc_reg_operand case fixed in a follow-up patch on gcc-patches: http://gcc.gnu.org/ml/gcc-patches/2017-01/msg02390.html plus the VSX pattern has been changed to allow DFmode which it didn't allow before. Not sure what to do about SFmode though, it might be too large changes and therefore GCC 8 matter? > The history is originally we had a define_expand and three separate insns, > one in rs6000.md that handled the non-VSX case, one in spe.md, and one in > vsx.md that handled VSX, and it had a common insn for DF, V2DF, and V4SF > modes. We later moved the scalar processing to rs6000.md. > > However, since spe.md has its own unsigned fix insns, and it uses wildly > different constraints, etc. we need to keep a separate define_expand, and > two define_insns (in rs6000.md and spe.md). > > Note, I have no way of testing SPE, other than by hand inspection of the > assembly code. Note SPE only has unsigned_fix:SI mode patterns, not :DI which is what is problematic here.
[Bug target/79197] [5/6/7 Regression] ICE in extract_insn in gcc/recog.c:2311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79197 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/71824] [6 Regression] ICE when compiling libiberty with Graphite loop optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71824 Richard Biener changed: What|Removed |Added Known to work||7.0.1 Summary|[6/7 Regression] ICE when |[6 Regression] ICE when |compiling libiberty with|compiling libiberty with |Graphite loop optimizations |Graphite loop optimizations Known to fail||6.3.0 --- Comment #12 from Richard Biener --- Fixed on trunk sofar.
[Bug middle-end/79310] -Wnonnull false positive on strlen after strstr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79310
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-02-01
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
match.pd is your friend.
(simplify
(ne (BUILT_IN_STRSTR @0 @1) integer_zerop)
(with
{
unsigned HOST_WIDE_INT string_length;
const char *p = c_getstr (@1, &string_length);
}
(if (p && string_length == 0)
{ constant_boolean_node (type, true); })))
etc.
[Bug pch/79306] ICE on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79306 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-02-01 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Usually an invalid use of PCH not correctly diagnosed. GCC 4.8 is no longer maintained and later releases contain mitigations against more invalid uses so please check at least GCC 5.
[Bug tree-optimization/79315] ICE while building SPEC CPU 2006 FP with -Ofast -ftree-parallelize-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79315 --- Comment #2 from Richard Biener --- Probably a "regression" since we do this verification. I'll try to reproduce on x86_64.
[Bug fortran/79313] associate statement inside openmp loop breaks OMP intrinisics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79313 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|unknown |6.3.0 Resolution|--- |INVALID --- Comment #4 from Richard Biener --- Thus invalid.
[Bug c/79319] New: sizeof returns the wrong size of a union containing aligned members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79319
Bug ID: 79319
Summary: sizeof returns the wrong size of a union containing
aligned members
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: erik at ehofman dot com
Target Milestone: ---
It looks like sizeof() returns an incorrect size if a union contains an aligned
member:
Consider the following code:
#include
typedef float vec4_t[4] __attribute__((aligned(32)));
typedef union {
float s4[4];
vec4_t v4;
} vec4f_t;
int main() {
printf("float[4]: %zi\n", sizeof(float[4]));
printf("vec4_t: %zi\n", sizeof(vec4_t));
printf("vec4f_t: %zi\n\n", sizeof(vec4f_t));
}
when running it prints:
__m128: 16
vec4_t: 16
vec4f_t: 32
As you can see both union members are 16-bytes but when quiring the size of the
union it returns the size of the alignment (change it to aligned(64) and the
size becomes 64).
[Bug rtl-optimization/79279] combine/simplify_set: wrong call to REG_CANNOT_CHANGE_MODE_P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79279 Aurelien Buhrig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Aurelien Buhrig --- According to the above gcc-patches discussion, checking m2 -> m1 is required to be sure that the new reg:m2 interpreted as m1 is valid. So both checks would be needed. But although the m1 -> m2 transformation is invalid, this change should be filtered by predicates (from general_operand) which wasn't. So no need to fix, unless maybe speeding up the combine process.
[Bug c/79319] sizeof returns the wrong size of a union containing aligned members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79319 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener --- This is as otherwise you can't build arrays with that type (so it has to have padding).
[Bug middle-end/79310] -Wnonnull false positive on strlen after strstr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79310
--- Comment #3 from Marc Glisse ---
We already have infer_nonnull_range_by_attribute ("Return true if OP can be
inferred to be a non-NULL after STMT executes by using attributes") and I
assume that strstr has the nonnull attribute in this example, so the match.pd
transform would be redundant (not that that's always bad). And it wouldn't help
anyway since strstr(s,"") gets replaced with "s" before we see the NE_EXPR.
There are many cases where a simplification loses range information. If I
simplify i-1+1 to just i, I lose the information that i cannot be INT_MIN,
which could be relevant to some other simplification later. I don't believe
there is an easy fix for that.
[Bug c++/79318] conversion member function preceded with & is not marked as error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79318
--- Comment #2 from Jakub Jelinek ---
Smaller testcase:
struct A
{
int a;
A () : a(0) {};
&operator int () { return a; };
};
int
bar ()
{
A a;
return a;
}
clang++ indeed reports:
pr79318.C:5:3: error: cannot specify any part of a return type in the
declaration of a conversion function; put the complete type after 'operator'
&operator int () { return a; };
^
&
[dcl.dcl]/12 indeed requires that conversion functions are declared with
nodeclspec-function-declaration.
[Bug c/79319] sizeof returns the wrong size of a union containing aligned members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79319 Erik Hofman changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from Erik Hofman --- Ah okay I hadn't thought of that. It's still confusing when encountering it for the first time.. Thanks for the answer.
[Bug tree-optimization/79315] [7 Regression] ICE while building SPEC CPU 2006 FP with -Ofast -ftree-parallelize-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79315 ktkachov at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-01 CC||ktkachov at gcc dot gnu.org Known to work||6.3.1 Target Milestone|--- |7.0 Summary|ICE while building SPEC CPU |[7 Regression] ICE while |2006 FP with -Ofast |building SPEC CPU 2006 FP |-ftree-parallelize-loops|with -Ofast ||-ftree-parallelize-loops Ever confirmed|0 |1 Known to fail||7.0 --- Comment #3 from ktkachov at gcc dot gnu.org --- Confirmed the ICE on the testcase. Doesn't ICE for me with GCC 6 so it's a regression
[Bug c/79319] sizeof returns the wrong size of a union containing aligned members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79319 --- Comment #3 from Marc Glisse --- It is a bit confusing indeed that vec4_t has sizeof: 16 and _Alignof: 32, one might expect an invariant that sizeof >= _Alignof... But just a typedef doesn't increase the size, while stuffing it in a struct/union does. And indeed if I try to make an array of vec4_t, I get the error: alignment of array elements is greater than element size. clang gives the same output on your program, and seems to ignore alignment if I make an array of vec4_t.
[Bug tree-optimization/79315] [7 Regression] ICE while building SPEC CPU 2006 FP with -Ofast -ftree-parallelize-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79315 Richard Biener changed: What|Removed |Added Target|aarch64-linux-gnu |aarch64-linux-gnu, ||x86_64-*-* Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug tree-optimization/79315] [7 Regression] ICE while building SPEC CPU 2006 FP with -Ofast -ftree-parallelize-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79315
--- Comment #4 from Richard Biener ---
The bogus location is on &__builtin_powf in
_224 = __builtin_powf (_38, 1.80942779541015625e+0);
in wsm32d. It gets the location via
#1 0x00ff33a5 in move_stmt_op (tp=0x766b3a90,
walk_subtrees=0x7fffd338, data=0x7fffd550)
at /space/rguenther/src/svn/gcc-7-branch/gcc/tree-cfg.c:6642
6642TREE_SET_BLOCK (t, p->new_block);
...
#5 0x00ff3ed7 in move_block_to_fn (dest_cfun=0x76a88160,
bb=,
after=, update_edge_count_p=true,
d=0x7fffd6e0)
at /space/rguenther/src/svn/gcc-7-branch/gcc/tree-cfg.c:6922
#6 0x00ff5783 in move_sese_region_to_fn (dest_cfun=0x76a88160,
(gdb) l
6637{
6638 tree block = TREE_BLOCK (t);
6639 if (block == p->orig_block
6640 || (p->orig_block == NULL_TREE
6641 && block != NULL_TREE))
6642TREE_SET_BLOCK (t, p->new_block);
6643 else if (flag_checking && block != NULL_TREE)
6644{
6645 while (block && TREE_CODE (block) == BLOCK && block !=
p->orig_block)
6646block = BLOCK_SUPERCONTEXT (block);
(gdb) p p->orig_bock
There is no member named orig_bock.
(gdb) p p->orig_block
$18 =
(gdb) p block
$19 =
(gdb) p p->new_block
$20 =
probably not a good idea to simply set TREE_BLOCK on a tree node that can
be shared... (from a NULL TREE_BLOCK even).
[Bug tree-optimization/79315] [7 Regression] ICE while building SPEC CPU 2006 FP with -Ofast -ftree-parallelize-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79315
--- Comment #5 from Richard Biener ---
Will test
Index: gcc/tree-cfg.c
===
--- gcc/tree-cfg.c (revision 245064)
+++ gcc/tree-cfg.c (working copy)
@@ -6636,11 +6636,12 @@ move_stmt_op (tree *tp, int *walk_subtre
if (EXPR_P (t))
{
tree block = TREE_BLOCK (t);
- if (block == p->orig_block
- || (p->orig_block == NULL_TREE
- && block != NULL_TREE))
+ if (block == NULL_TREE)
+ ;
+ else if (block == p->orig_block
+ || p->orig_block == NULL_TREE)
TREE_SET_BLOCK (t, p->new_block);
- else if (flag_checking && block != NULL_TREE)
+ else if (flag_checking)
{
while (block && TREE_CODE (block) == BLOCK && block != p->orig_block)
block = BLOCK_SUPERCONTEXT (block);
[Bug c/79319] sizeof returns the wrong size of a union containing aligned members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79319 --- Comment #4 from Erik Hofman --- This was just the shortest snippet of code that showed the situation. The reason for 32-byte alignment is that I use it with AVX code and wanted the fastest possible assignment from a float vector.
[Bug debug/70578] internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70578 --- Comment #6 from ishikawa,chiaki --- (In reply to ishikawa,chiaki from comment #5) > I have found that g++-5 can compile this without ICE. > So this is a regression in gcc-6. > > The version that worked is: > > g++-5 -v > Using built-in specs. > COLLECT_GCC=g++-5 > COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper > Target: x86_64-linux-gnu > Configured with: ../src/configure -v --with-pkgversion='Debian 5.4.1-4' > --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs > --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr > --program-suffix=-5 --enable-shared --enable-linker-build-id > --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix > --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu > --enable-libstdcxx-debug --enable-libstdcxx-time=yes > --with-default-libstdcxx-abi=new --enable-gnu-unique-object > --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib > --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo > --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home > --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 > --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 > --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar > --enable-objc-gc --enable-multiarch --with-arch-32=i686 --with-abi=m64 > --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic > --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu > --target=x86_64-linux-gnu > Thread model: posix > gcc version 5.4.1 20161202 (Debian 5.4.1-4) > ishikawa@debian-vbox-ci:/tmp$ Ouch, NO. GCC-5 is also vulnerable. gcc-5 also experienced an ICE on a different source file. So it is a problem with deeper root. /new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/media/libvpx/libvpx/vp9/decoder/vp9_dsubexp.c:72:1: internal compiler error: in output_index_string, at dwarf2out.c:22895 } ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. In the directory /home/ishikawa/objdir-tb3/media/libvpx The following command failed to execute properly: /usr/bin/ccache /usr/bin/gcc-5 -std=gnu99 -o vp9_dsubexp.o -c -I/home/ishikawa/objdir-tb3/dist/system_wrappers -include /new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1 -DHAVE_CONFIG_H=vpx_config.h -I/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/media/libvpx -I/home/ishikawa/objdir-tb3/media/libvpx -I/home/ishikawa/objdir-tb3/dist/include -I/home/ishikawa/objdir-tb3/dist/include/nspr -I/home/ishikawa/objdir-tb3/dist/include/nss -fPIC -include /home/ishikawa/objdir-tb3/mozilla-config.h -DMOZILLA_CLIENT -MD -MP -MF .deps/vp9_dsubexp.o.pp -Wall -Wempty-body -Wignored-qualifiers -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 -Werror=sign-compare -fno-strict-aliasing -fno-math-errno -pthread -pipe -gsplit-dwarf -g3 -Og -freorder-blocks -fno-omit-frame-pointer -I/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/media/libvpx/config/linux/x64/ -Wno-sign-compare -Wno-unused-function -I/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/media/libvpx/libvpx -I/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/media/libvpx/config /new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/media/libvpx/libvpx/vp9/decoder/vp9_dsubexp.c I am going to upload the preprocessed file.
[Bug c/79319] sizeof returns the wrong size of a union containing aligned members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79319 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Then consider using __builtin_assume_aligned rather than overaligning the elements.
[Bug c++/79308] ICE on specialization of nested template classes (in finish_member_declaration, at cp/semantics.c:2963)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79308 Martin Liška changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-01 CC||marxin at gcc dot gnu.org Summary|Internal compilation error |ICE on specialization of |on specialization of nested |nested template classes (in |template classes|finish_member_declaration, ||at cp/semantics.c:2963) Ever confirmed|0 |1 Known to fail||4.5.4, 4.6.4, 4.7.4, 4.8.5, ||4.9.4, 5.4.0, 6.3.0, 7.0 --- Comment #2 from Martin Liška --- Confirmed, all releases I have ICE (4.5.0+).
[Bug c++/69637] ICE on an invalid bit-field with template name for width
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69637 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #2 from Paolo Carlini --- Mine.
[Bug other/79250] brig/brigfrontend/brig-to-generic.cc: two small problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79250 --- Comment #2 from Pekka Jääskeläinen --- Committed in r245084.
[Bug debug/70578] internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70578 --- Comment #7 from ishikawa,chiaki --- Created attachment 40643 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40643&action=edit preprocessed file that caused gcc-5 to experience the similar ICE. The uploaded file was created by passing -savetemps option when gcc-5 experienced the ICE as reported earlier. The following simplified command line caused gcc-5 to experience the ICE. /usr/bin/gcc-5 -std=gnu99 -o vp9_dsubexp.o -c -DNDEBUG=1 \ -DTRIMMED=1 -DHAVE_CONFIG_H=vpx_config.h\ -fPIC \ -DMOZILLA_CLIENT\ -Wall -Wempty-body -Wignored-qualifiers \ -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code \ -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations \ -Wno-error=array-bounds -fno-builtin-strlen -Wl,--gdb-index \ -Dfdatasync=fdatasync -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 \ -Werror=sign-compare -fno-strict-aliasing -fno-math-errno -pthread \ -pipe -gsplit-dwarf -g3 -Og -freorder-blocks -fno-omit-frame-pointer\ -Wno-sign-compare -Wno-unused-function \ ./vp9_dsubexp.i > > > > > > > > > > > > /new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/media/libvpx/libvpx/vp9/decoder/vp9_dsubexp.c:72:1: > > > > > > > > > > > > internal compiler error: in output_index_string, at > > > > > > > > > > > > dwarf2out.c:22895 } ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. gcc-5 -v Using built-in specs. COLLECT_GCC=gcc-5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 5.4.1-4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.4.1 20161202 (Debian 5.4.1-4) ishikawa@debian-vbox-ci:/tmp$ TIA
[Bug c/79319] sizeof returns the wrong size of a union containing aligned members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79319 --- Comment #6 from Erik Hofman --- Thanks for the suggestion but after thinking it through some more I came to the conclusion I made a mistake. 32-byte alignment is only required for AVX when using 8-float (or 4-double) vectors. Otherwise the compiler would switch back to SSE which doesn't requite 32-byte alignment. So 32-byte alignment is required only when processing large arrays of floats. Sorry for the fuzz.
[Bug fortran/79311] ICE in generate_finalization_wrapper, at fortran/class.c:1992
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79311 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-01 CC||marxin at gcc dot gnu.org Summary|internal compiler error:|ICE in |generate_finalization_wrapp |generate_finalization_wrapp |er |er, at fortran/class.c:1992 Ever confirmed|0 |1 Known to fail||4.9.4, 5.4.0, 6.3.0, 7.0 --- Comment #1 from Martin Liška --- Confirmed, started to ICE with GCC 4.9.0.
[Bug c/79320] New: sqrt of negative number do not return NaN with i686-w64-mingw32-gcc on pentiumI7/Windows10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79320 Bug ID: 79320 Summary: sqrt of negative number do not return NaN with i686-w64-mingw32-gcc on pentiumI7/Windows10 Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: daniel.weil at argosim dot com Target Milestone: --- Created attachment 40644 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40644&action=edit Compile me With the cross-compiler i686-w64-mingw32-gcc.exe, on PentiumI7 with Windows10, the sqrt function returns identity instead of NaN. To reproduce the bug: - on a Pentium I7 with windows10 (tried with recent DELL XPS13) - install cygwin with the i686-w64-mingw32-gcc.exe cross-compiler - compiler the attached file ~~~ $ i686-w64-mingw32-gcc.exe -o essai essai.c -v && ./essai Utilisation des specs internes. COLLECT_GCC=i686-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/5.4.0/lto-wrapper.exe Cible : i686-w64-mingw32 Configuré avec: /cygdrive/i/szsz/tmpp/cygwin64/mingw64-i686/mingw64-i686-gcc-5.4 .0-3.i686/src/gcc-5.4.0/configure --srcdir=/cygdrive/i/szsz/tmpp/cygwin64/mingw6 4-i686/mingw64-i686-gcc-5.4.0-3.i686/src/gcc-5.4.0 --prefix=/usr --exec-prefix=/ usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/mingw64-i686- gcc --htmldir=/usr/share/doc/mingw64-i686-gcc/html -C --build=i686-pc-cygwin --h ost=i686-pc-cygwin --target=i686-w64-mingw32 --without-libiconv-prefix --without -libintl-prefix --with-sysroot=/usr/i686-w64-mingw32/sys-root --with-build-sysro ot=/usr/i686-w64-mingw32/sys-root --disable-multilib --disable-win32-registry -- enable-languages=c,ada,c++,fortran,lto,objc,obj-c++ --enable-fully-dynamic-strin g --enable-graphite --enable-libgomp --enable-libquadmath --enable-libquadmath-s upport --enable-libssp --enable-version-specific-runtime-libs --with-dwarf2 --wi th-gnu-ld --with-gnu-as --with-tune=generic --with-cloog-include=/usr/include/cl oog-isl --with-system-zlib --enable-threads=posix --libexecdir=/usr/lib Modèle de thread: posix gcc version 5.4.0 (GCC) COLLECT_GCC_OPTIONS='-o' 'essai.exe' '-v' '-mtune=generic' '-march=pentiumpro' /usr/lib/gcc/i686-w64-mingw32/5.4.0/cc1.exe -quiet -v -D_REENTRANT essai.c -qui et -dumpbase essai.c -mtune=generic -march=pentiumpro -auxbase essai -version -o /tmp/ccbqPl1C.s GNU C11 (GCC) version 5.4.0 (i686-w64-mingw32) compilé par GNU C version 5.4.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3 warning: GMP header version 6.1.0 differs from library version 6.1.2. warning: MPFR header version 3.1.4 differs from library version 3.1.5. heuristiques GGC: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 le répertoire « /usr/i686-w64-mingw32/sys-root/usr/local/include » est ignoré ca r inexistant le répertoire « /usr/lib/gcc/i686-w64-mingw32/5.4.0/../../../../i686-w64-mingw32 /include » est ignoré car inexistant la recherche pour #include "..." débute ici : la recherche pour #include <...> débute ici: /usr/lib/gcc/i686-w64-mingw32/5.4.0/include /usr/lib/gcc/i686-w64-mingw32/5.4.0/include-fixed /usr/i686-w64-mingw32/sys-root/mingw/include Fin de la liste de recherche. GNU C11 (GCC) version 5.4.0 (i686-w64-mingw32) compilé par GNU C version 5.4.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3 warning: GMP header version 6.1.0 differs from library version 6.1.2. warning: MPFR header version 3.1.4 differs from library version 3.1.5. heuristiques GGC: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 94288b9bd2212c08d70115a290bc41ca COLLECT_GCC_OPTIONS='-o' 'essai.exe' '-v' '-mtune=generic' '-march=pentiumpro' /usr/lib/gcc/i686-w64-mingw32/5.4.0/../../../../i686-w64-mingw32/bin/as.exe -v -o /tmp/ccDzZTqz.o /tmp/ccbqPl1C.s Version de l'assembleur GNU 2.25.51 (i686-w64-mingw32) utilisant la version BFD (GNU Binutils) 2.25.51.20150320 COMPILER_PATH=/usr/lib/gcc/i686-w64-mingw32/5.4.0/:/usr/lib/gcc/i686-w64-mingw32 /5.4.0/:/usr/lib/gcc/i686-w64-mingw32/:/usr/lib/gcc/i686-w64-mingw32/5.4.0/:/usr /lib/gcc/i686-w64-mingw32/:/usr/lib/gcc/i686-w64-mingw32/5.4.0/../../../../i686- w64-min
[Bug tree-optimization/79321] New: -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 Bug ID: 79321 Summary: -ftree-parallelize-loops miscompiles 400.perlbench Product: gcc Version: 7.0.1 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- Target: x86_64-*-* $summary, when I use -Ofast -ftree-parallelize-loops=4 -march=haswell on a 4-core machine - it seems to deadlock with TEST input (REF/TRAIN not checked). trunk r245080.
[Bug debug/70578] internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70578 --- Comment #8 from ishikawa,chiaki --- As for gcc-5 ICE, I observe an important thing after a little experimentation. This is a shortened command line that causes the ICE. /usr/bin/gcc-5 -std=gnu99 -o vp9_dsubexp.o -c -DNDEBUG=1 -DTRIMMED=1 \ -DHAVE_CONFIG_H=vpx_config.h -fPIC -DMOZILLA_CLIENT \ -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync\ -DDEBUG_4GB_CHECK -DUSEHELGRIND=1\ -gsplit-dwarf -g3 -Og ./vp9_dsubexp.i If I remove -gsplit-dwarf, I don't get the ICE. ishikawa@debian-vbox-ci:/tmp$ /usr/bin/gcc-5 -std=gnu99 -o vp9_dsubexp.o -c -DNDEBUG=1 -DTRIMMED=1 \ -DHAVE_CONFIG_H=vpx_config.h -fPIC -DMOZILLA_CLIENT \ -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync\ -DDEBUG_4GB_CHECK -DUSEHELGRIND=1\ -g3 -Og ./vp9_dsubexp.i > > > > ishikawa@debian-vbox-ci:/tmp$ But then, leaving -gsplit-dwarf intact, if I change "-g3" to "-g", I don't get an ICE. ishikawa@debian-vbox-ci:/tmp$ /usr/bin/gcc-5 -std=gnu99 -o vp9_dsubexp.o -c -DNDEBUG=1 -DTRIMMED=1 \ -DHAVE_CONFIG_H=vpx_config.h -fPIC -DMOZILLA_CLIENT \ -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync\ -DDEBUG_4GB_CHECK -DUSEHELGRIND=1\ -gsplit-dwarf -g -Og ./vp9_dsubexp.i > > > > ishikawa@debian-vbox-ci:/tmp$ So it could be a combination of -gsplit-dwarf and -g3 in my GCC-5 case. I have no idea what the cause of ICE for G++-6 case, though. TIA
[Bug tree-optimization/79315] [7 Regression] ICE while building SPEC CPU 2006 FP with -Ofast -ftree-parallelize-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79315 --- Comment #6 from Richard Biener --- On x86_64 I see a similar ICE when building 416.gamess
[Bug tree-optimization/67326] [5/6 Regression] -ftree-loop-if-convert-stores does not vectorize conditional assignment (anymore)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67326 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||law at gcc dot gnu.org Summary|[5/6/7 Regression] |[5/6 Regression] |-ftree-loop-if-convert-stor |-ftree-loop-if-convert-stor |es does not vectorize |es does not vectorize |conditional assignment |conditional assignment |(anymore) |(anymore) --- Comment #6 from Aldy Hernandez --- Fixed in trunk with: commit 189d070677016c1ea25553a3ab4d926c6c20a434 Author: amker Date: Mon May 9 11:44:03 2016 + * tree-if-conv.c (tree-ssa-loop.h): Include header file. (tree-ssa-loop-niter.h): Ditto. (idx_within_array_bound, ref_within_array_bound): New functions. (ifcvt_memrefs_wont_trap): Check if array ref is within bound. Factor out check on writable base object to ... (base_object_writable): ... here. gcc/testsuite/ * gcc.dg/tree-ssa/ifc-9.c: New test. * gcc.dg/tree-ssa/ifc-10.c: New test. * gcc.dg/tree-ssa/ifc-11.c: New test. * gcc.dg/tree-ssa/ifc-12.c: New test. * gcc.dg/vect/pr61194.c: Remove XFAIL. * gcc.dg/vect/vect-23.c: Remove XFAIL. * gcc.dg/vect/vect-mask-store-move-1.c: Revise test check. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@236026 138bc75d-0d04-0410-961f-82ee72b054a4 Removing GCC 7 regression marker.
[Bug tree-optimization/70137] internal compiler error: in add_phi_arg_for_new_expr, at graphite-isl-ast-to-gimple.c:2331
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70137 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-02-01 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Using ISL 0.16, I can't reproduce that on current for both x86_64 and aarch64. Can you please re-test that?
[Bug c/79320] sqrt of negative number do not return NaN with i686-w64-mingw32-gcc on pentiumI7/Windows10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79320 Richard Biener changed: What|Removed |Added Target||i686-w64-mingw32 --- Comment #1 from Richard Biener --- I doubt this is a GCC issue but rather either a mingw/windows runtime issue or a CPU issue if the assembly happens to use sqrt/fsqrt instructions (you'd have to check, you use an unoptimized compile).
[Bug tree-optimization/70137] internal compiler error: in add_phi_arg_for_new_expr, at graphite-isl-ast-to-gimple.c:2331
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70137 --- Comment #3 from ktkachov at gcc dot gnu.org --- I can't reproduce it anymore either. I guess it can be closed then
[Bug tree-optimization/67326] [5/6 Regression] -ftree-loop-if-convert-stores does not vectorize conditional assignment (anymore)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67326 Richard Biener changed: What|Removed |Added Known to work||5.1.0, 7.0 Target Milestone|7.0 |5.5 Known to fail||5.2.0, 6.1.0 --- Comment #7 from Richard Biener --- Unlikely to be backported (depends on too many refactorings IIRC).
[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 Bug 59859 depends on bug 70137, which changed state. Bug 70137 Summary: internal compiler error: in add_phi_arg_for_new_expr, at graphite-isl-ast-to-gimple.c:2331 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70137 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME
[Bug tree-optimization/70137] internal compiler error: in add_phi_arg_for_new_expr, at graphite-isl-ast-to-gimple.c:2331
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70137 Richard Biener changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME
[Bug libstdc++/78346] [5/6/7 Regression] std::search with binary comparison predicate uses invalid reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78346 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.5
[Bug libstdc++/78346] [5/6/7 Regression] std::search with binary comparison predicate uses invalid reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78346 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug libstdc++/78420] [5/6/7 Regression] std::less is not a total order with -O2 enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |5.5
[Bug c++/79113] [7 Regression] ICE inheriting a default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79113 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |7.0
[Bug other/79322] New: gcc-6.3.0 inconsistent libstdc++ and libgcc_s link for libcc1 and libgcj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79322 Bug ID: 79322 Summary: gcc-6.3.0 inconsistent libstdc++ and libgcc_s link for libcc1 and libgcj Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: edeveaud at pasteur dot fr Target Milestone: --- building and installing gcc-6.3.0 on non std directory lead to some libstdc++ link mismatch. most of the libraries are linked to gcc-6.3.0 installed libraries while some other are linked to system libraries libcc1.so is linked to -> /usr/lib64/libstdc++.so.6 instead of $PREFIX/lib64/libstdc++.so.6 /lib64/libgcc_s.so.1 instead of $PREFIX/lib64/libgcc_s.so.1 libgcj.so libgcj_bc.so libitm.so libstdc++.so are linked to -> /lib64/libgcc_s.so. instead of $PREFIX/lib64/libgcc_s.so.1 see: ldd /exe/gcc/6.3.0/lib64/*.so | grep -e '^/' -e 'libstdc++' -e libgcc_s 2> /err /exe/gcc/6.3.0/lib64/libasan.so: libstdc++.so.6 => /exe/gcc/6.3.0/lib/../lib64/libstdc++.so.6 (0x7f4208a53000) libgcc_s.so.1 => /exe/gcc/6.3.0/lib/../lib64/libgcc_s.so.1 (0x7f4208224000) /exe/gcc/6.3.0/lib64/libatomic.so: /exe/gcc/6.3.0/lib64/libcc1.so: libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x7f22cfe7b000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f22cf64c000) /exe/gcc/6.3.0/lib64/libcilkrts.so: libstdc++.so.6 => /exe/gcc/6.3.0/lib/../lib64/libstdc++.so.6 (0x7f3d0e35a000) libgcc_s.so.1 => /exe/gcc/6.3.0/lib/../lib64/libgcc_s.so.1 (0x7f3d0db2b000) /exe/gcc/6.3.0/lib64/libgcc_s.so: /exe/gcc/6.3.0/lib64/libgcj-tools.so: libgcc_s.so.1 => /exe/gcc/6.3.0/lib/../lib64/libgcc_s.so.1 (0x7ffa5b4a4000) /exe/gcc/6.3.0/lib64/libgcj.so: libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f10eba62000) /exe/gcc/6.3.0/lib64/libgcj_bc.so: libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7ff71e81c000) /exe/gcc/6.3.0/lib64/libgfortran.so: libgcc_s.so.1 => /exe/gcc/6.3.0/lib/../lib64/libgcc_s.so.1 (0x7ffb0610d000) /exe/gcc/6.3.0/lib64/libgij.so: libgcc_s.so.1 => /exe/gcc/6.3.0/lib/../lib64/libgcc_s.so.1 (0x7f7b15d19000) /exe/gcc/6.3.0/lib64/libgomp.so: /exe/gcc/6.3.0/lib64/libitm.so: libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7fbd7ef6c000) /exe/gcc/6.3.0/lib64/liblsan.so: libstdc++.so.6 => /exe/gcc/6.3.0/lib/../lib64/libstdc++.so.6 (0x7fdcd24c) libgcc_s.so.1 => /exe/gcc/6.3.0/lib/../lib64/libgcc_s.so.1 (0x7fdcd1c91000) /exe/gcc/6.3.0/lib64/libmpx.so: /exe/gcc/6.3.0/lib64/libquadmath.so: /exe/gcc/6.3.0/lib64/libssp.so: /exe/gcc/6.3.0/lib64/libstdc++.so: libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7fc460eef000) /exe/gcc/6.3.0/lib64/libtsan.so: libstdc++.so.6 => /exe/gcc/6.3.0/lib/../lib64/libstdc++.so.6 (0x7f963f239000) libgcc_s.so.1 => /exe/gcc/6.3.0/lib/../lib64/libgcc_s.so.1 (0x7f963ea0a000) /exe/gcc/6.3.0/lib64/libubsan.so: libstdc++.so.6 => /exe/gcc/6.3.0/lib/../lib64/libstdc++.so.6 (0x7fe3d5dfb000) libgcc_s.so.1 => /exe/gcc/6.3.0/lib/../lib64/libgcc_s.so.1 (0x7fe3d55cc000) similar to bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78097 best regards Eric additional infos: cat /etc/centos-release CentOS release 6.8 (Final) gcc-6.3.3 was compiled with head -n 8 /tmp/gcc-6.3.0/config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by configure, which was generated by GNU Autoconf 2.64. Invocation command line was $ /src/gcc/gcc-6.3.0/configure --prefix=/exe/gcc/6.3.0 --enable-threads=posix --enable-__cxa_atexit --disable-multilib --enable-java-home --with-jvm-root-dir=/exe/gcc/6.3.0/libexec/gcj --enable-languages=c,c++,fortran,java
[Bug tree-optimization/72712] [7 Regression] Tenfold compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72712 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed (somehow).
[Bug middle-end/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/19721] [meta-bug] optimizations that CSE still catches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721 Bug 19721 depends on bug 72712, which changed state. Bug 72712 Summary: [7 Regression] Tenfold compile time regression https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72712 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/78604] [7 regression] test case gcc.target/powerpc/p8vector-vectorize-1.c fails starting with r242750
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78604 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-01 Component|tree-optimization |target Ever confirmed|0 |1
[Bug c++/79077] [7 regression][new inheriting ctors] bad code for inherited ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79077 Richard Biener changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1
[Bug c++/79104] [7 Regression] ambiguity calling std::begin on a local constexpr array of structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79104 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-01 Ever confirmed|0 |1
[Bug libstdc++/79141] [6/7 Regression] std::pair p = {}; fails to compile due to ambiguous overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79141 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-01 Known to work|6.2.1 |5.3.0, 6.2.0 Ever confirmed|0 |1 Known to fail|6.3.1 |6.3.0, 7.0 --- Comment #1 from Richard Biener --- Confirmed.
[Bug libstdc++/79323] New: FAIL: 20_util/duration/literals/range.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79323
Bug ID: 79323
Summary: FAIL: 20_util/duration/literals/range.cc (test for
excess errors)
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
This testcase fails when compiled with -O0
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/chrono: In
instantiation of 'struct
std::literals::chrono_literals::_Checked_integral_constant':^M
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/chrono:903:
required from 'constexpr _Dur
std::literals::chrono_literals::__check_overflow() [with _Dur =
std::chrono::duration >; char ..._Digits = {'9',
'2', '2', '3', '3', '7', '2', '0', '3', '6', '8', '5', '4', '7', '7', '5', '8',
'0', '8'}]'^M
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/chrono:913:
required from here^M
/home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/20_util/duration/literals/range.cc:28:
in constexpr expansion of 'std::literals::chrono_literals::operator""h<'9',
'2', '2', '3', '3', '7', '2', '0', '3', '6', '8', '5', '4', '7', '7', '5', '8',
'0', '8'>()'^M
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/chrono:890:
error: static assertion failed: literal value cannot be represented by duration
type^M
[Bug libstdc++/79254] [5/6/7 Regression] basic_string::operator= isn't exception safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254 --- Comment #11 from Jonathan Wakely --- Author: redi Date: Wed Feb 1 11:41:48 2017 New Revision: 245085 URL: https://gcc.gnu.org/viewcvs?rev=245085&root=gcc&view=rev Log: PR libstdc++/79254 simplify exception-safety in copy assignment PR libstdc++/79254 * config/abi/pre/gnu.ver: Remove recently added symbols. * include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI] (basic_string::_M_copy_assign): Remove. (basic_string::operator=(const basic_string&)): Don't dispatch to _M_copy_assign. If source object is small just deallocate, otherwise perform new allocation before making any changes. * include/bits/basic_string.tcc [_GLIBCXX_USE_CXX11_ABI] (basic_string::_M_copy_assign(const basic_string&, true_type)): Remove. * testsuite/21_strings/basic_string/allocator/char/copy_assign.cc: Test cases where the allocators are equal or the string is small. * testsuite/21_strings/basic_string/allocator/wchar_t/copy_assign.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/include/bits/basic_string.h trunk/libstdc++-v3/include/bits/basic_string.tcc trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/copy_assign.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/copy_assign.cc
[Bug tree-optimization/71351] [7 Regression] ICE: Segmentation fault (graphite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71351
--- Comment #5 from Martin Liška ---
Just our of curiosity, why graphite does a transformation as original and AST
are same:
[scheduler] original ast:
{
for (int c0 = 0; c0 < P_19; c0 += 1) {
S_4(c0);
for (int c1 = 0; c1 <= 2; c1 += 1)
S_5(c0, c1);
S_7(c0);
}
S_9();
}
[scheduler] AST generated by isl:
{
for (int c0 = 0; c0 < P_19; c0 += 1) {
S_4(c0);
for (int c1 = 0; c1 <= 2; c1 += 1)
S_5(c0, c1);
S_7(c0);
}
S_9();
}
Doing a transformation should be easy in that case.
[Bug tree-optimization/71142] [6/7 Regression] ICE: Segmentation fault in ssa_default_def (graphite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71142 --- Comment #10 from Martin Liška --- Can't reproduce any of both tests on both x86_64-linux-gnu and aarach64. Is it still valid?
[Bug libstdc++/79323] FAIL: 20_util/duration/literals/range.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79323 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-02-01 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |minor --- Comment #1 from Jonathan Wakely --- Oh I think it's just the extra "in constexpr expansion of" output, which we can prune.
[Bug tree-optimization/71142] [6/7 Regression] ICE: Segmentation fault in ssa_default_def (graphite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71142 --- Comment #11 from ktkachov at gcc dot gnu.org --- (In reply to Martin Liška from comment #10) > Can't reproduce any of both tests on both x86_64-linux-gnu and aarach64. Is > it still valid? I can reproduce the ICE on the original testcase on GCC 6 but not trunk. I can't reproduce the ICE in the second testcase anywhere
[Bug libstdc++/79195] make_array should not ask for common_type when the type is explicitly specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79195 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Wed Feb 1 12:12:34 2017 New Revision: 245087 URL: https://gcc.gnu.org/viewcvs?rev=245087&root=gcc&view=rev Log: PR libstdc++/79195 fix make_array type deduction PR libstdc++/79195 * include/experimental/array (make_array): Use common_type<_Dest> and delay instantiation of common_type until after conditional_t. Qualify std::forward call. (to_array): Add exception specification. * testsuite/experimental/array/make_array.cc: Test argument types without a common type. Modified: branches/gcc-6-branch/libstdc++-v3/ChangeLog branches/gcc-6-branch/libstdc++-v3/include/experimental/array branches/gcc-6-branch/libstdc++-v3/testsuite/experimental/array/make_array.cc
[Bug libstdc++/79254] [5/6/7 Regression] basic_string::operator= isn't exception safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254 --- Comment #12 from Jonathan Wakely --- Author: redi Date: Wed Feb 1 12:12:28 2017 New Revision: 245086 URL: https://gcc.gnu.org/viewcvs?rev=245086&root=gcc&view=rev Log: PR libstdc++/79254 fix exception-safety of std::string copy assignment PR libstdc++/79254 * include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI] (basic_string::operator=(const basic_string&)): If source object is small just deallocate, otherwise perform new allocation before making any changes. * testsuite/21_strings/basic_string/allocator/wchar_t/copy_assign.cc: Test exception-safety of copy assignment when allocator propagates. * testsuite/21_strings/basic_string/allocator/char/copy_assign.cc: Likewise. * testsuite/util/testsuite_allocator.h (uneq_allocator::swap): Make std::swap visible. Modified: branches/gcc-6-branch/libstdc++-v3/ChangeLog branches/gcc-6-branch/libstdc++-v3/include/bits/basic_string.h branches/gcc-6-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/copy_assign.cc branches/gcc-6-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/copy_assign.cc branches/gcc-6-branch/libstdc++-v3/testsuite/util/testsuite_allocator.h
[Bug libstdc++/79254] [5/6/7 Regression] basic_string::operator= isn't exception safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254 --- Comment #13 from Jonathan Wakely --- Author: redi Date: Wed Feb 1 12:18:43 2017 New Revision: 245088 URL: https://gcc.gnu.org/viewcvs?rev=245088&root=gcc&view=rev Log: PR libstdc++/79254 fix exception-safety of std::string copy assignment PR libstdc++/79254 * include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI] (basic_string::operator=(const basic_string&)): If source object is small just deallocate, otherwise perform new allocation before making any changes. * testsuite/21_strings/basic_string/allocator/wchar_t/copy_assign.cc: Test exception-safety of copy assignment when allocator propagates. * testsuite/21_strings/basic_string/allocator/char/copy_assign.cc: Likewise. * testsuite/util/testsuite_allocator.h (uneq_allocator::swap): Make std::swap visible. Modified: branches/gcc-5-branch/libstdc++-v3/ChangeLog branches/gcc-5-branch/libstdc++-v3/include/bits/basic_string.h branches/gcc-5-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/copy_assign.cc branches/gcc-5-branch/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/copy_assign.cc branches/gcc-5-branch/libstdc++-v3/testsuite/util/testsuite_allocator.h
[Bug libstdc++/79195] make_array should not ask for common_type when the type is explicitly specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79195 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.4 --- Comment #5 from Jonathan Wakely --- Fixed for 6.4
[Bug libstdc++/79254] [5/6/7 Regression] basic_string::operator= isn't exception safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79254 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Jonathan Wakely --- Fixed for 5.5, 6.4 and 7.1
[Bug other/79322] gcc-6.3.0 inconsistent libstdc++ and libgcc_s link for libcc1 and libgcj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79322 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-01 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- It probably depends on whether we use libtool to re-link at make install time (to set the proper runpath). For example libcc1 has a runpath for me but libstdc++ does not.
[Bug libstdc++/56862] std::complex constructor ambiguous overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56862
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Jonathan Wakely ---
(In reply to cbcode from comment #0)
> std::complex cc(number()); //OK
This is only OK because it's a function declaration, not a variable definition.
See https://en.wikipedia.org/wiki/Most_vexing_parse
If you change it to be a variable then you get the same ambiguity:
std::complex cc{number()}; // ambiguous
std::complex cc = number(); // ambiguous
std::complex cc = std::complex(number()); // ambiguous
And that's correct, there are two user-defined conversions that can be used to
construct a std::complex from a number, so this is not a bug.
[Bug libstdc++/78975] uniform_real_distribution should not check RealType with is_floating_point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78975 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |8.0 --- Comment #3 from Jonathan Wakely --- It's too late to make this change for GCC 7 now.
[Bug tree-optimization/79315] [7 Regression] ICE while building SPEC CPU 2006 FP with -Ofast -ftree-parallelize-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79315 --- Comment #7 from Richard Biener --- Author: rguenth Date: Wed Feb 1 12:47:25 2017 New Revision: 245089 URL: https://gcc.gnu.org/viewcvs?rev=245089&root=gcc&view=rev Log: 2017-02-01 Richard Biener PR middle-end/79315 * tree-cfg.c (move_stmt_op): Never set TREE_BLOCK when it was not set before. * gfortran.dg/pr79315.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr79315.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c
[Bug libstdc++/78346] [5/6/7 Regression] std::search with binary comparison predicate uses invalid reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78346 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Wed Feb 1 12:57:46 2017 New Revision: 245091 URL: https://gcc.gnu.org/viewcvs?rev=245091&root=gcc&view=rev Log: PR78346 make handle stashing iterators PR libstdc++/78346 * include/bits/predefined_ops.h (_Iter_equals_iter): Store iterator not its referent. (_Iter_comp_to_iter): Likewise. * testsuite/25_algorithms/search/78346.cc: New test. Added: branches/gcc-6-branch/libstdc++-v3/testsuite/25_algorithms/search/78346.cc Modified: branches/gcc-6-branch/libstdc++-v3/ChangeLog branches/gcc-6-branch/libstdc++-v3/include/bits/predefined_ops.h
[Bug libstdc++/78346] [5/6/7 Regression] std::search with binary comparison predicate uses invalid reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78346 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Wed Feb 1 12:57:35 2017 New Revision: 245090 URL: https://gcc.gnu.org/viewcvs?rev=245090&root=gcc&view=rev Log: PR78346 make handle stashing iterators PR libstdc++/78346 * include/bits/predefined_ops.h (_Iter_equals_iter): Store iterator not its referent. (_Iter_comp_to_iter): Likewise. * testsuite/25_algorithms/search/78346.cc: New test. Added: trunk/libstdc++-v3/testsuite/25_algorithms/search/78346.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/predefined_ops.h
[Bug tree-optimization/76957] [7 regression] FAIL: gcc.dg/graphite/scop-dsyr2k.c scan-tree-dump-times graphite "number of SCoPs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76957 --- Comment #10 from Richard Biener --- Author: rguenth Date: Wed Feb 1 12:58:27 2017 New Revision: 245094 URL: https://gcc.gnu.org/viewcvs?rev=245094&root=gcc&view=rev Log: 2017-02-01 Richard Biener PR testsuite/76957 * gcc.dg/graphite/scop-dsyr2k-2.c: New testcase. * gcc.dg/graphite/scop-dsyrk-2.c: Likewise. * gcc.dg/graphite/scop-dsyr2k.c: XFAIL. * gcc.dg/graphite/scop-dsyrk.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/graphite/scop-dsyr2k-2.c trunk/gcc/testsuite/gcc.dg/graphite/scop-dsyrk-2.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/graphite/scop-dsyr2k.c trunk/gcc/testsuite/gcc.dg/graphite/scop-dsyrk.c
[Bug libstdc++/78346] [5/6/7 Regression] std::search with binary comparison predicate uses invalid reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78346 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Wed Feb 1 12:57:58 2017 New Revision: 245092 URL: https://gcc.gnu.org/viewcvs?rev=245092&root=gcc&view=rev Log: PR78346 make handle stashing iterators PR libstdc++/78346 * include/bits/predefined_ops.h (_Iter_equals_iter): Store iterator not its referent. (_Iter_comp_to_iter): Likewise. * testsuite/25_algorithms/search/78346.cc: New test. Added: branches/gcc-5-branch/libstdc++-v3/testsuite/25_algorithms/search/78346.cc Modified: branches/gcc-5-branch/libstdc++-v3/ChangeLog branches/gcc-5-branch/libstdc++-v3/include/bits/predefined_ops.h
[Bug libstdc++/78346] [5/6/7 Regression] std::search with binary comparison predicate uses invalid reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78346 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jonathan Wakely --- Fixed for 5.5, 6.4 and 7.1
[Bug tree-optimization/76957] [7/8 Regression] XFAIL: gcc.dg/graphite/scop-dsyr2k.c scan-tree-dump-times graphite "number of SCoPs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76957 Richard Biener changed: What|Removed |Added Keywords||xfail Priority|P4 |P2 Known to work||6.3.0 Blocks|59859 | Target Milestone|7.0 |8.0 Summary|[7 regression] FAIL:|[7/8 Regression] XFAIL: |gcc.dg/graphite/scop-dsyr2k |gcc.dg/graphite/scop-dsyr2k |.c scan-tree-dump-times |.c scan-tree-dump-times |graphite "number of SCoPs |graphite "number of SCoPs Known to fail||7.0.1 --- Comment #11 from Richard Biener --- XFAILed on trunk, defering niter analysis solution to GCC 8. This isn't a graphite issue, so P2. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 [Bug 59859] [meta-bug] GRAPHITE issues
[Bug tree-optimization/71351] [7 Regression] ICE: Segmentation fault (graphite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71351 Martin Liška changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #6 from Martin Liška --- *** Bug 71142 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 Bug 59859 depends on bug 71142, which changed state. Bug 71142 Summary: [6/7 Regression] ICE: Segmentation fault in ssa_default_def (graphite) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71142 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/71142] [6/7 Regression] ICE: Segmentation fault in ssa_default_def (graphite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71142 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #12 from Martin Liška --- (In reply to ktkachov from comment #11) > (In reply to Martin Liška from comment #10) > > Can't reproduce any of both tests on both x86_64-linux-gnu and aarach64. Is > > it still valid? > > I can reproduce the ICE on the original testcase on GCC 6 but not trunk. > I can't reproduce the ICE in the second testcase anywhere Ok, thanks. It really disappeared on trunk with the Richi's patch that does reorganization in pass manager. Anyhow, as I debugged that on GCC6 branch, it's dup of PR71351. Which still has a reproducible test-case. *** This bug has been marked as a duplicate of bug 71351 ***
[Bug c/12245] [5/6/7 regression] Uses lots of memory when compiling large initialized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245 --- Comment #62 from Richard Biener --- Main issue is still for GCC: Kind Nodes Bytes constants1630852 39140573 integer_cst 1630844 c/c-typeck.c:9020 (output_init_element) 0: 0.0% 33554552: 50.0% 33554440: 31.2% 152: 0.2%20 and for G++: Kind Nodes Bytes constants1630864 39140861 integer_cst 1630856 cp/constexpr.c:4814 (maybe_constant_value) 67108816:100.0% 100663104 17: 0.0% ggc (huh!) cp/parser.c:21811 (cp_parser_initializer_list) 33554440: 99.8% 33554552: 8.3% 0: 0.0% 152: 0.1%20 that maybe_constant_value can be improved to cp/constexpr.c:4817 (maybe_constant_value) 2032: 13.6% 2144 2: 0.0% ggc with a simple patch.
[Bug c/12245] [5/6/7 regression] Uses lots of memory when compiling large initialized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245 --- Comment #63 from Richard Biener --- Sth that could pay off with other testcases (nested CONSTRUCTORs) is to truncate the size of the CONSTRUCTOR_ELTS vec<> to the exact final size after parsing it as it will never grow again and we over-allocate during safe-pushing to it. vec:: has no suitable function to do that (yet) though. It won't help this particular testcase of course.
[Bug libquadmath/79317] logq is returning double precision results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79317 --- Comment #1 from ggoeckel at presby dot edu --- My error. Sorry. Double precision entered with this assignment. lntwo=6.9314718055994530941723212145817446e-01
[Bug go/79281] gccgo: Binaries using goroutines crash on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281 --- Comment #7 from Ian Lance Taylor --- It sounds like you have a patch for GCC 6. If you send it in I can apply it. The error you show must be from `make -j`, as compiling a file in libgfortran would not invoke go1. What is the actual failure?
[Bug c/79320] sqrt of negative number do not return NaN with i686-w64-mingw32-gcc on pentiumI7/Windows10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79320 --- Comment #2 from Daniel WEIL --- OK. I log the issue on mingw bugs : https://sourceforge.net/p/mingw/bugs/2337/
[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-01 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Well, it's not GCC 7 regression, problem is that we generate a GOMP_parallel. After it's done, the main thread is going to do fork/exec: #0 __libc_fork () at ../sysdeps/nptl/fork.c:49 #1 0x004ef765 in Perl_my_fork () at util.c:2303 #2 0x004915f6 in Perl_pp_fork () at pp_sys.c:4009 #3 0x004acccd in Perl_runops_standard () at run.c:37 #4 0x00445f28 in S_run_body (oldscope=1) at perl.c:2017 #5 perl_run (my_perl=) at perl.c:1934 #6 0x004034a2 in main (argc=4, argv=0x7fffdb88, env=) at perlmain.c:98 (gdb) info threads Id Target Id Frame * 1Thread 0x77fae780 (LWP 3579) "perlbench_base." __libc_fork () at ../sysdeps/nptl/fork.c:49 2Thread 0x770e6700 (LWP 3583) "perlbench_base." do_spin (val=8, addr=0x77e044) at ../../../libgomp/config/linux/wait.h:56 3Thread 0x768e5700 (LWP 3584) "perlbench_base." futex_wait (val=8, addr=0x77e044) at ../../../libgomp/config/linux/x86/futex.h:44 4Thread 0x760e4700 (LWP 3585) "perlbench_base." futex_wait (val=8, addr=0x77e044) at ../../../libgomp/config/linux/x86/futex.h:44 and that's why the other threads will not reach the barrier.
[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 --- Comment #2 from Martin Liška --- And running with OMP_NUM_LIMIT=1 works fine.
[Bug testsuite/79272] FAIL: gcc.dg/ipa/pr77653.c scan-ipa-dump icf "Not unifying; alias cannot be created; target is discardable"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79272 --- Comment #6 from Martin Liška --- Author: marxin Date: Wed Feb 1 14:04:38 2017 New Revision: 245095 URL: https://gcc.gnu.org/viewcvs?rev=245095&root=gcc&view=rev Log: Add dg-require-alias to a ICF test (PR testsuite/79272). 2017-02-01 Martin Liska PR testsuite/79272 * gcc.dg/ipa/pr77653.c: Add dg-require-alias to the test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/ipa/pr77653.c
[Bug testsuite/79272] FAIL: gcc.dg/ipa/pr77653.c scan-ipa-dump icf "Not unifying; alias cannot be created; target is discardable"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79272 Martin Liška changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Liška --- Fixed.
[Bug go/79281] gccgo: Binaries using goroutines crash on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281 --- Comment #8 from James Clarke --- Created attachment 40645 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40645&action=edit Proposed fix I believe this patch is what Adrian did; Adrian, can you please confirm?
[Bug go/79281] gccgo: Binaries using goroutines crash on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79281 John Paul Adrian Glaubitz changed: What|Removed |Added CC||glaubitz at physik dot fu-berlin.d ||e --- Comment #9 from John Paul Adrian Glaubitz --- Comment on attachment 40645 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40645 Proposed fix Yes, this is the correct fix for gcc-6.
[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866 --- Comment #8 from Martin Liška --- Is affected just the arm-none-eabi target, or are any others?
[Bug c++/79307] g++ misses warning for reference on temporary that invokes undefined behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79307
--- Comment #4 from Szikra ---
> This is bug 44974.
>
> > Possible duplicate of bug #44859 or bug #51270.
>
> Looks more like bug 49974 to me.
>
> *** This bug has been marked as a duplicate of bug 44974 ***
Hi you are right, my first example is the same as in bug 49974:
struct Y {
Y(int& i) : r(i) { }
int& r;
};
If that were fixed, it would probably solve both problem.
Though my second case might be easier to detect, or it's more obviously wrong
:)
struct TestRefIntDirect {
TestRefIntDirect(int a) : a_(a) {};
const int& a_;
};
This is wrong by in itself, in this case temporary is always created and in the
same place where it is used.
But I have a problem:
Shouldn't this be marked as duplicate of bug 49974 and not bug 44974? :)
[Bug c++/79300] Wrong diagnostics position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79300 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-02-01 Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Confirmed. I'm looking into this.
[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- May I close it as invalid?
[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 Martin Liška changed: What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |---
[Bug tree-optimization/79321] -ftree-parallelize-loops miscompiles 400.perlbench
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 --- Comment #4 from rguenther at suse dot de --- On Wed, 1 Feb 2017, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79321 > > Martin Liška changed: > >What|Removed |Added > > Status|NEW |RESOLVED > Resolution|--- |FIXED > > --- Comment #3 from Martin Liška --- > May I close it as invalid? Well, why did we parallelize a loop with a fork() call?
