[Bug c++/66852] vmovdqa instructions issued on 64-bit aligned array, causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852 --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- See PR65709 for a similar issue.
[Bug c++/66858] New: [6 Regression] FAIL: g++.dg/pch/system-2.C -O2 -g assembly comparison on aarch64-none-elf, arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66858 Bug ID: 66858 Summary: [6 Regression] FAIL: g++.dg/pch/system-2.C -O2 -g assembly comparison on aarch64-none-elf, arm-none-eabi Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org CC: jason at redhat dot com Target Milestone: --- Target: aarch64-none-elf, arm-none-eabi Created attachment 35968 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35968action=edit g++.log entry for the failure I'm seeing this failure on a bare-metal aarch64-none-elf (newlib target) after: Author: jason jason@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Wed Jul 1 18:27:12 2015 + gcc/c-family/ * c-opts.c (c_common_post_options): Default to C++14. * gcc/testsuite/ lib/target-supports.exp (cxx_default): Set to C++14. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@225272 138bc75d-0d04-0410-961f-82ee72b054a4 I'm attaching the log entry from the assembly comparison test. Running the test with /-std=gnu++98 works fine. I don't see this failure on linux targets (glibc based)
[Bug c++/66852] vmovdqa instructions issued on 64-bit aligned array, causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852
--- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(In reply to Richard Biener from comment #6)
So I suppose the IsAligned template is wrong.
Yes.
390 template class T
391 inline unsigned int GetAlignmentOf(T *dummy=NULL) // VC60 workaround
392 {
393 #ifdef CRYPTOPP_ALLOW_UNALIGNED_DATA_ACCESS
394 if (sizeof(T) 16)
395 return 1;
396 #endif
397
398 #if (_MSC_VER = 1300)
399 return __alignof(T);
400 #elif defined(__GNUC__)
401 return __alignof__(T);
402 #elif CRYPTOPP_BOOL_SLOW_WORD64
403 return UnsignedMin(4U, sizeof(T));
404 #else
405 return sizeof(T);
406 #endif
407 }
408
409 inline bool IsAlignedOn(const void *p, unsigned int alignment)
410 {
411 return alignment==1 || (IsPowerOf2(alignment) ?
ModPowerOf2((size_t)p, alignment) == 0 : (size_t)p % alignment == 0);
412 }
413
414 template class T
415 inline bool IsAligned(const void *p, T *dummy=NULL) // VC60 workaround
416 {
417 return IsAlignedOn(p, GetAlignmentOfT());
418 }
and
345 #if CRYPTOPP_BOOL_X64 || CRYPTOPP_BOOL_X86 || defined(__powerpc__)
346 #define CRYPTOPP_ALLOW_UNALIGNED_DATA_ACCESS
347 #endif
The only architecture where the assumption is valid is POWER8, where
unaligned vector loads are preferable to ones with forced-alignment.
[Bug c++/66852] vmovdqa instructions issued on 64-bit aligned array, causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- The code in algparam.h is just disgusting. AssignFromHelperClass binds a reference to NULL just to default-construct a temporary of some type, then binds a const-reference to that temporary, then casts away const to modify the value of that temporary. What seems to be a VC60 workaround introduces undefined behaviour by trying to be far too clever. Apparently also too clever to use compiler warnings.
[Bug c++/66852] vmovdqa instructions issued on 64-bit aligned array, causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852 --- Comment #9 from Jeffrey Walton noloader at gmail dot com --- (In reply to Jonathan Wakely from comment #8) The code in algparam.h is just disgusting. AssignFromHelperClass binds a reference to NULL just to default-construct a temporary of some type, then binds a const-reference to that temporary, then casts away const to modify the value of that temporary. What seems to be a VC60 workaround introduces undefined behaviour by trying to be far too clever. Apparently also too clever to use compiler warnings. Lol... Yeah, some of the legacy code is awful. I'm not throwing stones because the library supported so many compilers and IDEs back then. I think its time to start cleaning up some of the cruft. I'm going to cite this comment when I propose some of the changes.
[Bug tree-optimization/65709] [5 Regression] Bad code for LZ4 decompression with -O3 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65709
Jeffrey Walton noloader at gmail dot com changed:
What|Removed |Added
CC||noloader at gmail dot com
--- Comment #14 from Jeffrey Walton noloader at gmail dot com ---
(In reply to Jakub Jelinek from comment #10)
(In reply to Yann Collet from comment #9)
Looking at the assembler generated, we see that GCC generates a MOVDQA
instruction for it.
movdqa (%rdi,%rax,1),%xmm0
$rdi=0x7fffea4b53e6
$rax=0x0
This seems wrong on 2 levels :
- The function only wants to copy 8 bytes. MOVDQA works on a full SSE
register, which is 16 bytes. This spell troubles, if only for buffer
boundaries checks : the algorithm uses 8 bytes because it knows it can
safely read/write that size without crossing buffer limits. With 16 bytes,
no such guarantee.
The function has been inlined into the callers, like:
do { LZ4_copy8(d,s); d+=8; s+=8; } while (de);
and this loop is then vectorized. The vectorization prologue of course has
to adjust if s is not 16 byte aligned, but it can assume that both s and d
are 8 byte aligned (otherwise it is undefined behavior)...
Forgive my barging in Jakub. I was referred to this issue and comment from
another issue.
Its not clear to me where the leap is made that its OK use vmovdqa. Are you
stating (unequivocally, for folks like me) that is does *not* matter what the
alignment is in the C-sources; and that the prologue ensures both 's' and 's'
are eventually 16-byte aligned when vmovdqa is invoked. That is, when we see
vmovdqa used, we know the alignment is correct (and at 16-bytes).
Sorry to have to ask.
[Bug tree-optimization/46193] ICE: in omp_reduction_init, at omp-low.c:2212 with -ftree-parallelize-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46193 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #4 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01018.html
[Bug c/66842] libatomic uses multiple locks for locked atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66842 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Component|libstdc++ |c --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- This obviously isn't a libstdc++ bug because you're not even using C++!
[Bug tree-optimization/65709] [5 Regression] Bad code for LZ4 decompression with -O3 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65709 --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org --- I'm saying that if the program does not trigger undefined behavior (e.g. by accessing misaligned integers without telling the compiler about it (by using memcpy, or packed attribute or pragma), then it would be a compiler bug to use an instruction requiring higher alignment than guaranteed in the source, without ensuring such alignment (through realigning arrays, introducing a loop for aligning pointers before the vectorized loop, peeling a few iterations needed to align the pointer(s), or using instructions that don't require such high alignment). No testcase has been provided here without having undefined behavior in them that would show a bug on the compiler side.
[Bug c++/66857] Reference not bound to lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66857 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-13 Ever confirmed|0 |1
[Bug c++/66852] vmovdqa instructions issued on 64-bit aligned array, causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |INVALID --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- If you build with -fsanitize=undefined you'll see: algparam.h:204:87: runtime error: reference binding to null pointer of type 'const struct Integer' algparam.h:217:88: runtime error: reference binding to null pointer of type 'const struct Integer' algparam.h:220:88: runtime error: reference binding to null pointer of type 'const struct Integer' crc.cpp:134:28: runtime error: load of misaligned address 0x0127df9f for type 'const word32', which requires 4 byte alignment filters.cpp:280:39: runtime error: null pointer passed as argument 1, which is declared to never be null filters.cpp:280:39: runtime error: null pointer passed as argument 2, which is declared to never be null filters.cpp:281:50: runtime error: null pointer passed as argument 1, which is declared to never be null filters.cpp:281:50: runtime error: null pointer passed as argument 2, which is declared to never be null filters.cpp:291:28: runtime error: null pointer passed as argument 1, which is declared to never be null filters.cpp:518:84: runtime error: null pointer passed as argument 1, which is declared to never be null filters.cpp:518:84: runtime error: null pointer passed as argument 2, which is declared to never be null filters.cpp:676:35: runtime error: null pointer passed as argument 2, which is declared to never be null misc.cpp:101:29: runtime error: load of misaligned address 0x7ffdab82d529 for type 'word32', which requires 4 byte alignment misc.cpp:101:50: runtime error: load of misaligned address 0x0127df95 for type 'word32', which requires 4 byte alignment misc.cpp:26:43: runtime error: load of misaligned address 0x7ffdab82c713 for type 'word64', which requires 8 byte alignment misc.cpp:35:43: runtime error: load of misaligned address 0x03c65c4a for type 'word32', which requires 4 byte alignment misc.cpp:56:68: runtime error: store to misaligned address 0x03c67653 for type 'word64', which requires 8 byte alignment misc.cpp:66:67: runtime error: store to misaligned address 0x03c67651 for type 'word32', which requires 4 byte alignment misc.cpp:91:30: runtime error: load of misaligned address 0x7ffdab82d511 for type 'word64', which requires 8 byte alignment misc.h:1163:31: runtime error: load of misaligned address 0x0127d8aa for type 'const unsigned int', which requires 4 byte alignment misc.h:1181:2: runtime error: load of misaligned address 0x03c67669 for type 'const unsigned int', which requires 4 byte alignment misc.h:177:26: runtime error: null pointer passed as argument 2, which is declared to never be null misc.h:623:22: runtime error: shift exponent 32 is too large for 32-bit type 'unsigned int' misc.h:635:22: runtime error: shift exponent 32 is too large for 32-bit type 'unsigned int' misc.h:641:22: runtime error: shift exponent 32 is too large for 32-bit type 'unsigned int' misc.h:962:23: runtime error: load of misaligned address 0x7ffdab82c702 for type 'const long long unsigned int', which requires 8 byte alignment panama.cpp:371:11: runtime error: load of misaligned address 0x7ffdab82c716 for type 'const word32', which requires 4 byte alignment panama.cpp:371:18: runtime error: load of misaligned address 0x7ffdab82c71a for type 'const word32', which requires 4 byte alignment panama.cpp:371:25: runtime error: load of misaligned address 0x7ffdab82c71e for type 'const word32', which requires 4 byte alignment ... etc.
[Bug c++/66852] vmovdqa instructions issued on 64-bit aligned array, causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852 --- Comment #11 from Jeffrey Walton noloader at gmail dot com --- (In reply to Jonathan Wakely from comment #8) The code in algparam.h is just disgusting. AssignFromHelperClass binds a reference to NULL just to default-construct a temporary of some type, then binds a const-reference to that temporary, then casts away const to modify the value of that temporary. What seems to be a VC60 workaround introduces undefined behaviour by trying to be far too clever. Apparently also too clever to use compiler warnings. The project is finally using -Wall, and its not flagging any issues with that code. I know -Wdelete-non-virtual-dtor is a problem (and potential security problem), and I'm trying to figure how how to proceed. Cf.https://groups.google.com/d/msg/cryptopp-users/__m0euOdbEQ/tvINItctzjAJ, What additional warnings would you suggest?
[Bug libgcc/66809] stage 1 build failure in libgcc on sparc-sun-solaris2.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66809 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- I personally build the GMP/MPFR/MPC libraries with --disable-shared.
[Bug tree-optimization/65709] [5 Regression] Bad code for LZ4 decompression with -O3 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65709 --- Comment #16 from Jeffrey Walton noloader at gmail dot com --- (In reply to Jakub Jelinek from comment #15) I'm saying that if the program does not trigger undefined behavior (e.g. by accessing misaligned integers without telling the compiler about it (by using memcpy, or packed attribute or pragma), then it would be a compiler bug to use an instruction requiring higher alignment than guaranteed in the source, without ensuring such alignment (through realigning arrays, introducing a loop for aligning pointers before the vectorized loop, peeling a few iterations needed to align the pointer(s), or using instructions that don't require such high alignment). No testcase has been provided here without having undefined behavior in them that would show a bug on the compiler side. OK, so you'll have to forgive my ignorance again. So you are saying that it may be a bug to use vmovdqa if the source and/or destination are not 16-byte aligned; but all the user code you have seen has undefined behavior so you're not going to answer. Is that correct? (My apologies if its too sharp a point. I'm just trying to figure out what the preconditions are for vmovdqa, and if it should be used when source or destination is 8-byte aligned).
[Bug tree-optimization/66856] New: [6 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66856 Bug ID: 66856 Summary: [6 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:234 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 35966 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35966action=edit vectorizer dump Firefox built with -flto and -O3 produces following ICE: /home/marxin/Programming/gecko-dev/gfx/cairo/libpixman/src/pixman-fast-path.c: In function ‘fast_write_back_r5g6b5’: /home/marxin/Programming/gecko-dev/gfx/cairo/libpixman/src/pixman-fast-path.c:2459:1: internal compiler error: in compute_live_loop_exits, at tree-ssa-loop-manip.c:234 fast_write_back_r5g6b5 (pixman_iter_t *iter) ^ 0xc8ed62 compute_live_loop_exits ../../gcc/tree-ssa-loop-manip.c:234 0xc8ed62 add_exit_phis_var ../../gcc/tree-ssa-loop-manip.c:321 0xc8ed62 add_exit_phis ../../gcc/tree-ssa-loop-manip.c:343 0xc8ed62 rewrite_into_loop_closed_ssa(bitmap_head*, unsigned int) ../../gcc/tree-ssa-loop-manip.c:538 0xd87283 vectorize_loops() ../../gcc/tree-vectorizer.c:586 Unfortunately, as it's a ltrans issue, it won't be hard to come up with a small reproducer. Thus, I attached vectorizer dump file, hope it will help. Thanks, Martin
[Bug c++/66555] Fails to warn for if (j == 0 i == i)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66555 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |6.0
[Bug c++/66857] Reference not bound to lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66857 --- Comment #1 from Sebastian Lauwers sebastian.lauwers at gmail dot com --- Command: g++ -v -save-temps test.cpp Output: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --with-default-libstdcxx-abi=c++98 --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-redhat-linux/5.1.1/cc1plus -E -quiet -v -D_GNU_SOURCE test.cpp -mtune=generic -march=x86-64 -fpch-preprocess -o test.ii ignoring nonexistent directory /usr/lib/gcc/x86_64-redhat-linux/5.1.1/include-fixed ignoring nonexistent directory /usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../x86_64-redhat-linux/include #include ... search starts here: #include ... search starts here: /usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../include/c++/5.1.1 /usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../include/c++/5.1.1/x86_64-redhat-linux /usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../include/c++/5.1.1/backward /usr/lib/gcc/x86_64-redhat-linux/5.1.1/include /usr/local/include /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-redhat-linux/5.1.1/cc1plus -fpreprocessed test.ii -quiet -dumpbase test.cpp -mtune=generic -march=x86-64 -auxbase test -version -o test.s GNU C++ (GCC) version 5.1.1 20150618 (Red Hat 5.1.1-4) (x86_64-redhat-linux) compiled by GNU C version 5.1.1 20150618 (Red Hat 5.1.1-4), GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (GCC) version 5.1.1 20150618 (Red Hat 5.1.1-4) (x86_64-redhat-linux) compiled by GNU C version 5.1.1 20150618 (Red Hat 5.1.1-4), GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: a5de1e39a9a4df73d4ab91471f1f5942 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' as -v --64 -o test.o test.s GNU assembler version 2.25 (x86_64-redhat-linux) using BFD version version 2.25-8.fc22 COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/:/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/5.1.1/:/usr/lib/gcc/x86_64-redhat-linux/ LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/5.1.1/:/usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-redhat-linux/5.1.1/collect2 -plugin /usr/libexec/gcc/x86_64-redhat-linux/5.1.1/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper -plugin-opt=-fresolution=test.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id --no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/5.1.1/crtbegin.o -L/usr/lib/gcc/x86_64-redhat-linux/5.1.1 -L/usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../.. test.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-redhat-linux/5.1.1/crtend.o /usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64/crtn.o
[Bug c++/66852] vmovdqa instructions issued on 64-bit aligned array, causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |WAITING Last reconfirmed||2015-07-13 CC||rguenth at gcc dot gnu.org Version|4.9.0 |4.9.2 Ever confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Please at least attach preprocessed source of the file containing xorbuf ()
[Bug libgcc/66854] New: libgcc2.c:1846:9: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66854 Bug ID: 66854 Summary: libgcc2.c:1846:9: internal compiler error: Segmentation fault Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: sebastian.hu...@embedded-brains.de Target Milestone: --- make[4]: Entering directory `/scratch/git-build/b-gcc-git-powerpc-rtems4.11/powerpc-rtems4.11/m403/libgcc' # If this is the top-level multilib, build all the other # multilibs. /scratch/git-build/b-gcc-git-powerpc-rtems4.11/./gcc/xgcc -B/scratch/git-build/b-gcc-git-powerpc-rtems4.11/./gcc/ -nostdinc -B/scratch/git-build/b-gcc-git-powerpc-rtems4.11/powerpc-rtems4.11/newlib/ -isystem /scratch/git-build/b-gcc-git-powerpc-rtems4.11/powerpc-rtems4.11/newlib/targ-include -isystem /home/EB/sebastian_h/archive/gcc-git/newlib/libc/include -B/opt/rtems-4.11/powerpc-rtems4.11/bin/ -B/opt/rtems-4.11/powerpc-rtems4.11/lib/ -isystem /opt/rtems-4.11/powerpc-rtems4.11/include -isystem /opt/rtems-4.11/powerpc-rtems4.11/sys-include-g -O2 -mcpu=403 -O2 -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc/. -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../gcc -I/home/EB/sebastian_h/archive/gcc-git/libgcc/../include -DHAVE_CC_TLS -o _powisf2.o -MT _powisf2.o -MD -MP -MF _powisf2.dep -DL_powisf2 -c /home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS /home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c: In function '__powisf2': /home/EB/sebastian_h/archive/gcc-git/libgcc/libgcc2.c:1846:9: internal compiler error: Segmentation fault x = x * x; ^ 0xa5ea6f crash_signal /home/EB/sebastian_h/archive/gcc-git/gcc/toplev.c:352 0xd63016 tree_class_check /home/EB/sebastian_h/archive/gcc-git/gcc/tree.h:3236 0xd63016 rs6000_pass_by_reference /home/EB/sebastian_h/archive/gcc-git/gcc/config/rs6000/rs6000.c:10836 0x56bb84 pass_by_reference(rs6000_args*, machine_mode, tree_node*, bool) /home/EB/sebastian_h/archive/gcc-git/gcc/calls.c:878 0x56d1cf emit_library_call_value_1 /home/EB/sebastian_h/archive/gcc-git/gcc/calls.c:4033 0x573ff1 emit_library_call_value(rtx_def*, rtx_def*, libcall_type, machine_mode, int, ...) /home/EB/sebastian_h/archive/gcc-git/gcc/calls.c:4631 0x984cd7 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*, int, optab_methods) /home/EB/sebastian_h/archive/gcc-git/gcc/optabs.c:2133 0x670f1e expand_mult(machine_mode, rtx_def*, rtx_def*, rtx_def*, int) /home/EB/sebastian_h/archive/gcc-git/gcc/expmed.c:3266 0x6902b6 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /home/EB/sebastian_h/archive/gcc-git/gcc/expr.c:8598 0x582482 expand_gimple_stmt_1 /home/EB/sebastian_h/archive/gcc-git/gcc/cfgexpand.c:3340 0x582482 expand_gimple_stmt /home/EB/sebastian_h/archive/gcc-git/gcc/cfgexpand.c:3400 0x5847ad expand_gimple_basic_block /home/EB/sebastian_h/archive/gcc-git/gcc/cfgexpand.c:5412 0x589d0e execute /home/EB/sebastian_h/archive/gcc-git/gcc/cfgexpand.c:6023 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [_powisf2.o] Error 1
[Bug c++/66852] vmovdqa instructions issued on 64-bit aligned array, causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852 --- Comment #10 from Jeffrey Walton noloader at gmail dot com --- (In reply to Richard Biener from comment #6) So I suppose the IsAligned template is wrong. So I'm clear (please forgive my ignorance)... According to http://www.felixcloutier.com/x86/MOVDQA.html, vmovdqa requires values double quad word alignment (16-byte). A word64 is aligned on 8-bytes, and does not meet the precondition to use the instruction. Naively, that seems like a problem to me. Will that create problems with GCC and vectorizations?
[Bug rtl-optimization/58066] __tls_get_addr is called with misaligned stack on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 --- Comment #14 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Uroš Bizjak from comment #13) Patch in testing. This patch fixes the testcase, now we get: inet_ntoa: 0: 41 56 push %r14 2: 41 55 push %r13 4: 44 0f b6 ef movzbl %dil,%r13d 8: 41 54 push %r12 a: 55 push %rbp b: 41 89 fcmov%edi,%r12d e: 53 push %rbx f: 89 fb mov%edi,%ebx 11: 41 c1 ec 10 shr$0x10,%r12d 15: 0f b6 c7movzbl %bh,%eax 18: c1 eb 18shr$0x18,%ebx 1b: 45 0f b6 e4 movzbl %r12b,%r12d 1f: 41 89 c6mov%eax,%r14d 22: 48 8d 3d 00 00 00 00lea0(%rip),%rdi# 29 inet_ntoa+0x29 25: R_X86_64_TLSLD buffer+0xfffc 29: e8 00 00 00 00 callq 2e inet_ntoa+0x2e 2a: R_X86_64_PLT32 __tls_get_addr+0xfffc 2e: 48 83 ec 08 sub$0x8,%rsp 32: 48 8d 15 00 00 00 00lea0(%rip),%rdx# 39 inet_ntoa+0x39 35: R_X86_64_PC32 .LC0+0xfffc 39: 45 89 e1mov%r12d,%r9d 3c: 48 8d a8 00 00 00 00lea0x0(%rax),%rbp 3f: R_X86_64_DTPOFF32 buffer 43: 53 push %rbx 44: 45 89 f0mov%r14d,%r8d 47: 44 89 e9mov%r13d,%ecx 4a: 31 c0 xor%eax,%eax 4c: be 12 00 00 00 mov$0x12,%esi 51: 48 89 efmov%rbp,%rdi 54: e8 00 00 00 00 callq 59 inet_ntoa+0x59 55: R_X86_64_PLT32 __snprintf+0xfffc 59: 58 pop%rax 5a: 48 89 e8mov%rbp,%rax 5d: 5a pop%rdx 5e: 5b pop%rbx 5f: 5d pop%rbp 60: 41 5c pop%r12 62: 41 5d pop%r13 64: 41 5e pop%r14 66: c3 retq The difference between patched (+++) and unpatched (---) code is: --- pr58066_.s 2015-07-13 11:58:23.0 +0200 +++ pr58066.s 2015-07-13 11:58:26.0 +0200 @@ -28,16 +28,16 @@ movzbl %bh, %eax shrl$24, %ebx movzbl %r12b, %r12d - subq$8, %rsp -.LCFI5: movl%eax, %r14d leaqbuffer@tlsld(%rip), %rdi call__tls_get_addr@PLT - pushq %rbx -.LCFI6: + subq$8, %rsp +.LCFI5: leaq.LC0(%rip), %rdx movl%r12d, %r9d leaqbuffer@dtpoff(%rax), %rbp + pushq %rbx +.LCFI6: movl%r14d, %r8d movl%r13d, %ecx xorl%eax, %eax HJ, can you please test the patch if it fixes your problem?
[Bug ipa/66760] [4.9/5/6 Regression] compile time regression in IPA inline analysis on PR26854 testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66760 --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org --- Paolo has submitted a patch for this issue to the mailing list: https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00984.html
[Bug tree-optimization/65709] [5 Regression] Bad code for LZ4 decompression with -O3 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65709
--- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Jeffrey Walton from comment #16)
OK, so you'll have to forgive my ignorance again.
So you are saying that it may be a bug to use vmovdqa if the source and/or
destination are not 16-byte aligned; but all the user code you have seen has
undefined behavior so you're not going to answer. Is that correct?
(My apologies if its too sharp a point. I'm just trying to figure out what
the preconditions are for vmovdqa, and if it should be used when source or
destination is 8-byte aligned).
I'm saying we as the compiler writers know what we are doing, and the various
cases like using unaligned accesses or peeling for alignment or versioning for
alignment, or realigning arrays are handled in the compiler.
They do assume that the source is valid and does not trigger undefined
behavior.
If you e.g. compile on x86_64 with -O3 -mavx2
void
foo (int *a, int *b)
{
int i;
for (i = 0; i 64; i++)
a[i] = 2 * b[i];
}
you'll see that compiler decided to peel for alignment of b pointer and you can
see an (unrolled) scalar loop first that handles first few iterations to align
b if it is not already aligned, and then the main vector loop uses
vmovdqa for loads and vmovups for stores (because the a pointer modulo 32 might
not be the same as b pointer modulo 32). If you compile with -O2
-ftree-vectorize -mavx2, you'll see that peeling for alignment isn't performed,
as it enlarges the code, and vmovdqu is used for the loads instead.
The peeling for alignment assumes that there is no undefined behavior
originally, so if you call this with (uintptr) b % sizeof (int) != 0, it will
not work properly, but that is a bug in the code, not in the compiler.
So, if you have some testcase where there is no undefined behavior triggered
(try various sanitizers, inspect the code yourself, read the C standard), and
you are convinced the compiler introduces a bug where there isn't originally
(i.e. miscompiles the code), feel free to file a new bugreport.
Nothing like that has been presented in this PR.
[Bug fortran/64589] [OOP] Linking error due to undefined integer symbol with unlimited polymorphism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64589 --- Comment #5 from vehre at gcc dot gnu.org --- Author: vehre Date: Mon Jul 13 09:01:54 2015 New Revision: 225730 URL: https://gcc.gnu.org/viewcvs?rev=225730root=gccview=rev Log: gcc/testsuite/ChangeLog: 2015-07-13 Andre Vehreschild ve...@gcc.gnu.org PR fortran/64589 * gfortran.dg/pr64589.f90: New test. gcc/fortran/ChangeLog: 2015-07-13 Andre Vehreschild ve...@gcc.gnu.org PR fortran/64589 * class.c (find_intrinsic_vtab): Put/Search vtabs for intrinsic types in the top-level namespace. Added: trunk/gcc/testsuite/gfortran.dg/pr64589.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/testsuite/ChangeLog
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #47 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Another cosmetic issue that I've noticed is that an extra newline is added after every quoted comment. For example: test reply
[Bug rtl-optimization/58066] __tls_get_addr is called with misaligned stack on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 --- Comment #13 from Uroš Bizjak ubizjak at gmail dot com --- Created attachment 35964 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35964action=edit Combined middle/end/target patch Patch in testing.
[Bug rtl-optimization/58066] __tls_get_addr is called with misaligned stack on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #12 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Uroš Bizjak from comment #11)
Please make 64bit TLS patterns dependant on SP_REG, in the same way as 32bit
are.
This wont't fix this particular case, but this dependency would be nice to
have.
The problem with the testcase from Comment #10 is caused by stack
anti-adjustment, emitted from calls.c:
1: NOTE_INSN_DELETED
4: NOTE_INSN_BASIC_BLOCK 2
2: r96:SI=di:SI
3: NOTE_INSN_FUNCTION_BEG
6: {sp:DI=sp:DI-0x8;clobber flags:CC;} --- *** here ***
REG_ARGS_SIZE 0x8
7: {r98:SI=r96:SI 00x10;clobber flags:CC;}
8: {r99:QI=r98:SI#00x;clobber flags:CC;}
9: r100:SI=zero_extend(r99:QI)
10: r101:QI#0=zero_extract(r96:SI,0x8,0x8)
11: r102:SI=zero_extend(r101:QI)
12: r103:SI=zero_extend(r96:SI#0)
13: ax:DI=call [`__tls_get_addr'] argc:0
REG_EH_REGION 0x8000
14: r105:DI=ax:DI
REG_EQUAL unspec[0] 21
15: {r106:DI=r105:DI+const(unspec[`buffer'] 6);clobber flags:CC;}
16: r104:DI=r106:DI
REG_EQUAL `buffer'
17: {r108:SI=r96:SI 00x18;clobber flags:CC;}
18: r109:SI=zero_extend(r108:SI#0)
19: [pre sp:DI+=0xfff8]=r109:SI
REG_ARGS_SIZE 0x10
20: r9:SI=r100:SI
21: r8:SI=r102:SI
22: cx:SI=r103:SI
23: dx:DI=`*.LC0'
24: si:DI=0x12
25: di:DI=r104:DI
26: ax:QI=0
27: call [`__snprintf'] argc:0x10
REG_CALL_DECL `__snprintf'
28: ax:DI=call [`__tls_get_addr'] argc:0
REG_EH_REGION 0x8000
29: r111:DI=ax:DI
REG_EQUAL unspec[0] 21
30: {r112:DI=r111:DI+const(unspec[`buffer'] 6);clobber flags:CC;}
31: r95:DI=r112:DI
REG_EQUAL `buffer'
32: {sp:DI=sp:DI+0x10;clobber flags:CC;}
REG_ARGS_SIZE 0
36: ax:DI=r95:DI
37: use ax:DI
Putting a breakpoint on anti_adjust_stack will show where it happens:
Breakpoint 1, anti_adjust_stack (adjust=0x2e7b0500) at
/home/uros/gcc-svn/trunk/gcc/explow.c:902
902 if (adjust == const0_rtx)
(gdb) bt
#0 anti_adjust_stack (adjust=0x2e7b0500) at
/home/uros/gcc-svn/trunk/gcc/explow.c:902
#1 0x0080f24c in expand_call (exp=0x2e7b3680, target=0x0,
ignore=1) at /home/uros/gcc-svn/trunk/gcc/calls.c:3165
#2 0x00966084 in expand_expr_real_1 (exp=0x2e7b3680, target=0x0,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0, inner_reference_p=false)
at /home/uros/gcc-svn/trunk/gcc/expr.c:10362
There is already precompute_register_parameters function where:
/* If the value is a non-legitimate constant, force it into a
pseudo now. TLS symbols sometimes need a call to resolve. */
if (CONSTANT_P (args[i].value)
!targetm.legitimate_constant_p (args[i].mode, args[i].value))
args[i].value = force_reg (args[i].mode, args[i].value);
So, the core of the problem is in the call infrastructure that should emit
precomputed register parameters before anti_adjust_stack is emitted
After this infrastructure problem is fixed, proposed SP_REG dependency will
prevent stack adjustment to be scheduled above TLS patterns.
Re-confirmed as RTL-optimization problem.
[Bug c++/66852] vmovdqa instructions issued on 64-bit aligned array, causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852 --- Comment #12 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Jeffrey Walton from comment #10) (In reply to Richard Biener from comment #6) So I suppose the IsAligned template is wrong. So I'm clear (please forgive my ignorance)... According to http://www.felixcloutier.com/x86/MOVDQA.html, vmovdqa requires values double quad word alignment (16-byte). A word64 is aligned on 8-bytes, and does not meet the precondition to use the instruction. Naively, that seems like a problem to me. Will that create problems with GCC and vectorizations? See PR65709 Comment 9 and followups.
[Bug rtl-optimization/58066] __tls_get_addr is called with misaligned stack on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 --- Comment #15 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Uroš Bizjak from comment #13) Created attachment 35964 [details] Combined middle/end/target patch Patch in testing. I tried it on GCC 5 and it works on glibc. Thanks.
[Bug c++/66857] New: Reference not bound to lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66857
Bug ID: 66857
Summary: Reference not bound to lvalue
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.lauwers at gmail dot com
Target Milestone: ---
Created attachment 35967
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35967action=edit
preprocessed code
Reporting this as it seems to be a regression from gcc 4.9.2. The following
code works on gcc 4.9.2, but asserts on gcc 5.1.1:
=== 8 ==
#include cassert
const int i = 0;
struct Test {
Test(const int rhs) {
assert(rhs == i);
}
};
int main(void) {
Test test = i;
}
=== 8 ==
If line 12 is changed to:
Test test(i);
The assertion is not triggered.
Please let me know if further information is required.
[Bug c++/66852] vmovdqa instructions issued on 64-bit aligned array, causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- So I suppose the IsAligned template is wrong.
[Bug tree-optimization/66726] missed optimization, factor conversion out of COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66726 --- Comment #9 from Andreas Schwab sch...@linux-m68k.org --- On m68k: FAIL: gcc.dg/pr46309.c scan-tree-dump-times reassoc1 Optimizing range tests a_[0-9]*.D. -.1, 1. and -.3, 3.[\n\r]* into 1 FAIL: gcc.dg/pr46309.c scan-tree-dump-times reassoc1 Optimizing range tests a_[0-9]*.D. -.1, 1. and -.2, 2.[\n\r]* into 1 FAIL: gcc.dg/pr46309.c scan-tree-dump-times reassoc1 Optimizing range tests a_[0-9]*.D. -.0, 31. and -.64, 95.[\n\r]* into 2 $ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.dg/pr46309.c -O2 -fdump-tree-reassoc-details -S -o pr46309.s $ grep -e Optimizing range tests -e into pr46309.c.*.reassoc1 Optimizing range tests a_2(D) -[1, 1] and -[2, 2] and -[3, 3] and -[4, 4] into (unsigned int) a_2(D) + 4294967295 3 Optimizing range tests a_2(D) -[1, 1] and -[2, 2] and -[3, 3] and -[4, 4] into (unsigned int) a_2(D) + 4294967295 3 Optimizing range tests a_2(D) -[0, 31] and -[64, 95] into (a_2(D) 4294967231) 31 Optimizing range tests a_2(D) -[128, 159] and -[192, 223] into (a_2(D) 4294967231) + 4294967168 31
[Bug libstdc++/66855] New: codecvt wrong endianness in UTF-16 conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66855 Bug ID: 66855 Summary: codecvt wrong endianness in UTF-16 conversions Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: delrieutheo at gmail dot com Target Milestone: --- Created attachment 35965 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35965action=edit The buggy one There is a problem with codecvt, the facet codecvt_utf8_utf16 should do big-endian conversions with default template arguments. However this is the output I get linking with libstdc++-5.1.1 : UTF-16 [b098] [b294] [d0dc] [c624] UTF-16 to UTF-8 [eb] [82] [98] [eb] [8a] [94] [ed] [83] [9c] [ec] [98] [a4] Converting back to UTF-16 [98b0] [94b2] [dcd0] [24c6] The same code gives the expected result on OS X with libc++ and on Windows. When I specify the third template argument of codecvt_utf8_utf16 with std::little_endian, it gives the expected output.
[Bug libstdc++/65913] Linking failure without -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65913 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-13 Ever confirmed|0 |1 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- We should get Richard's patch reviewed so it can be included in 5.3
[Bug libstdc++/66855] codecvt wrong endianness in UTF-16 conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66855 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-07-13 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- mine
[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848 --- Comment #8 from Jack Howarth howarth.at.gcc at gmail dot com --- Note that radr://21372179 has been closed by Apple as behaves as expected' so that they believe the bug lies in the FSF gcc boehm-gc code.
[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834 --- Comment #10 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Jason Merrill from comment #9) So it seems that applying the DR 1430 tentative resolution to concepts severely limits the usability of variadic concepts, and we should reconsider that, so that instead we delay normalization of template-ids with variadic arguments until instantiation time. The restriction on expansion arguments to non-expansion parameters initially applied to all variadic templates until N2555, which Eric was also involved with... I guess I'll revert my change for the moment.
[Bug fortran/66864] New: floor function error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66864 Bug ID: 66864 Summary: floor function error Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dm577216smith at gmail dot com Target Milestone: --- Here is a small program showing an error in the FLOOR function on my machine. I get similar results with gfortran 5.1 and also an older 4.6 version. I noticed that each of the incorrect results, 94906264, 777666496, and 200004 seem to be the correct value chopped to 24 bits. Also, if I compile the program with 64-bit integers with -fdefault-integer-8, all the results are ok. PROGRAM T DOUBLE PRECISION :: X WRITE (*,*) ' ' X = 2.0D0 ** 26.5D0 WRITE (*,*) ' X = 2.0D0 ** 26.5D0 = ', X WRITE (*,*) ' FLOOR(X) = ', FLOOR(X) WRITE (*,*) ' ' WRITE (*,*) ' But FLOOR( 2.0D0 ** 26.5D0 ) = ', FLOOR( 2.0D0 ** 26.5D0 ) WRITE (*,*) ' ' WRITE (*,*) ' ' X = 777666555.6D0 WRITE (*,*) ' X = 777666555.6D0 gives ', X,' FLOOR(X) = ', FLOOR(X) WRITE (*,*) ' ' WRITE (*,*) ' But FLOOR(777666555.6D0) = ', FLOOR(777666555.6D0) WRITE (*,*) ' ' WRITE (*,*) ' ' X = 2000111222.6D0 WRITE (*,*) ' X = 2000111222.6D0 gives ', X,' FLOOR(X) = ', FLOOR(X) WRITE (*,*) ' ' WRITE (*,*) ' But FLOOR(2000111222.6D0) = ', FLOOR(2000111222.6D0) WRITE (*,*) ' ' WRITE (*,*) ' ' END PROGRAM T Output from the program: X = 2.0D0 ** 26.5D0 =94906265.624251559 FLOOR(X) = 94906265 But FLOOR( 2.0D0 ** 26.5D0 ) = 94906264 X = 777666555.6D0 gives777666555.6002FLOOR(X) =777666555 But FLOOR(777666555.6D0) =777666496 X = 2000111222.6D0 gives2000111222.599FLOOR(X) = 2000111222 But FLOOR(2000111222.6D0) = 200004
[Bug ipa/66863] New: wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66863
Bug ID: 66863
Summary: wrong code at -Os and above on x86_64-linux-gnu
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The current gcc trunk mis-compiles the following code on x86_64-linux-gnu at
-Os and above in both 32-bit and 64-bit modes.
This is a regression from 5.1.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150713 (experimental) [trunk revision 225727] (GCC)
$
$ gcc-trunk -O1 small.c; ./a.out
$ gcc-5.1 -Os small.c; ./a.out
$
$ gcc-trunk -Os small.c
$ ./a.out
Floating point exception (core dumped)
$
-
int a, b;
int
fn1 (int p1)
{
if (p1 -2147483647)
return 0;
else
return 1;
}
int
fn2 (int p1, short p2)
{
return p2 ? p1 % p2 : 0;
}
int
main ()
{
b = fn2 (fn1 (a), a);
return 0;
}
[Bug middle-end/23664] fold does not change (aC1)+(bC2) to (aC1)|(bC2) iff (C1 C2) == 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23664 hs.naveen naveen_gcc at indiatimes dot com changed: What|Removed |Added CC||naveen_gcc at indiatimes dot com --- Comment #4 from hs.naveen naveen_gcc at indiatimes dot com --- Fixed with the commit:- https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=a76fc0fddcdc434b187c067d3a4632fb8473153a
[Bug c++/66852] vmovdqa instructions issued on 64-bit aligned array, causes segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66852 --- Comment #13 from Jeffrey Walton noloader at gmail dot com --- A quick update We did out best to take the advice of Jakub, Janathan, Markus and others: https://github.com/weidai11/cryptopp/commit/9bf0eed0f6ff6d0b0a2d277e5401d69dc8c0e394. We are paying for past transgressions, and cleanup is not as easy as we would like. Eventually, we want to enable CRYPTOPP_NO_UNALIGNED_DATA_ACCESS by default. It removes all related undefined behavior flagged by UBsan. The only thing stopping us is the politics of such a move.
[Bug c++/66092] [c++-concepts] Concept can't check variadic template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66092 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Jul 14 04:11:11 2015 New Revision: 225758 URL: https://gcc.gnu.org/viewcvs?rev=225758root=gccview=rev Log: PR c++/66092 PR c++/66834 * gcc/cp/pt.c (coerce_template_parms): Revert earlier change. Removed: branches/c++-concepts/gcc/testsuite/g++.dg/concepts/dr1430.C Modified: branches/c++-concepts/ChangeLog.concepts branches/c++-concepts/gcc/cp/pt.c
[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834 --- Comment #11 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Jul 14 04:11:11 2015 New Revision: 225758 URL: https://gcc.gnu.org/viewcvs?rev=225758root=gccview=rev Log: PR c++/66092 PR c++/66834 * gcc/cp/pt.c (coerce_template_parms): Revert earlier change. Removed: branches/c++-concepts/gcc/testsuite/g++.dg/concepts/dr1430.C Modified: branches/c++-concepts/ChangeLog.concepts branches/c++-concepts/gcc/cp/pt.c
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 23664, which changed state. Bug 23664 Summary: fold does not change (aC1)+(bC2) to (aC1)|(bC2) iff (C1 C2) == 0 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23664 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/23664] fold does not change (aC1)+(bC2) to (aC1)|(bC2) iff (C1 C2) == 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23664 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- So closing as fixed.
[Bug c++/66857] [5/6 Regression] Reference not bound to lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66857 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||trippels at gcc dot gnu.org --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Started with r217814.
[Bug libstdc++/66829] [6 Regression] FAIL: 23_containers/multiset/modifiers/erase/dr130-linkage-check.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66829
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
We either need to change how we build testsuite_shared.cc, or change what goes
into it.
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -668,7 +668,7 @@ proc v3-build_support { } {
# Compile with -w so that warnings issued by the compiler
# do not prevent compilation.
if { [v3_target_compile $srcdir/util/$f $object_file sharedlib \
-[list incdir=$srcdir additional_flags=-fno-inline -w -shared
-fPIC -DPIC]]
+[list incdir=$srcdir additional_flags=-fno-inline -w -shared
-fPIC -DPIC -std=gnu++98]]
!= } {
error could not compile $f
}
[Bug libstdc++/63345] Multiple undefined behaviors (static_cast) in libstdc++-v3/include/bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63345 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- I believe all the real problems are fixed now.
[Bug tree-optimization/66856] [6 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.c:234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66856 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c++/66857] [5/6 Regression] Reference not bound to lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66857 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- The gimple dump shows a temporary int being created from the global, and the temporary is passed to the constructor.
[Bug c++/66859] New: internal compiler error: in lower_stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66859 Bug ID: 66859 Summary: internal compiler error: in lower_stmt Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: t at sharklasers dot com Target Milestone: --- Host: x86_64 Created attachment 35969 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35969action=edit minimal example $ g++ -fcilkplus test.cpp test.cpp: In function ‘void func(std::__cxx11::string)’: test.cpp:5:9: warning: statement has no effect [-Wunused-value] line; ^ test.cpp: In function ‘built-in’: test.cpp:11:30: internal compiler error: in lower_stmt, at gimple-low.c:396 cilk_spawn func(line); ^ 0xfe0d53 lower_stmt ../../gcc-5.1.0/gcc/gimple-low.c:396 0xfe0d53 lower_sequence ../../gcc-5.1.0/gcc/gimple-low.c:227 0xfe0dd2 lower_try_catch ../../gcc-5.1.0/gcc/gimple-low.c:469 0xfe0dd2 lower_stmt ../../gcc-5.1.0/gcc/gimple-low.c:291 0xfe0dd2 lower_sequence ../../gcc-5.1.0/gcc/gimple-low.c:227 0xfe0b5c lower_stmt ../../gcc-5.1.0/gcc/gimple-low.c:296 0xfe0b5c lower_sequence ../../gcc-5.1.0/gcc/gimple-low.c:227 0xfe09b1 lower_gimple_bind ../../gcc-5.1.0/gcc/gimple-low.c:441 0xfe180d lower_function_body ../../gcc-5.1.0/gcc/gimple-low.c:131 0xfe180d execute ../../gcc-5.1.0/gcc/gimple-low.c:205 The error does not appear if func takes the string by reference. openSUSE 13.2 (Harlequin) (x86_64) $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=local/gcc5.1/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-5.1.0/configure --prefix=local/gcc5.1 --enable-languages=c,c++,fortran --enable-gold=yes --enable-ld=yes --enable-lto --enable-bootstrap --disable-multilib Thread model: posix gcc version 5.1.0 (GCC)
[Bug tree-optimization/66851] support double reduction in parloops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66851 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization, patch Version|unknown |6.0 Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org --- Comment #2 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01057.html
[Bug tree-optimization/66862] OpenMP SIMD does not work (use SIMD instructions) on conditional code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66862 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |tree-optimization --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- There is an optimization which should have converted the loop to use uncondtional stores. I wonder why it is not happening in this case.
[Bug tree-optimization/66828] [5/6 Regression] gcc/tree-ssa-math-opts.c:2182:38: runtime error: left shift of 72057594037927936 by 8 places cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66828 --- Comment #2 from Thomas Preud'homme thopre01 at gcc dot gnu.org --- The C standard says nothing about the cumulative effect of several shift so I'm guessing that the real issue is probably that the type is signed. Quoting C99 section 6.5.8 paragraph 4: If E1 has a signed type and nonnegative value, and E1 × 2E2 is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined. Which is the case for the last iteration.
[Bug c++/63522] [4.8/4.9/5 Regression] ICE: unexpected expression 'ElementIndices' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63522
aaron.mcdaid at gmail dot com changed:
What|Removed |Added
CC||aaron.mcdaid at gmail dot com
--- Comment #5 from aaron.mcdaid at gmail dot com ---
Hi,
In which versions has this been fixed? I'm running 4.9.3 and it crashes with
this fragment. I had assumed that 4.9.3 was very up-to-date (as of July 2015).
Perhaps this was fixed in the 5.x series and wasn't included in the recent
4.9.3 release?
I also have a different piece of code that gives a very similar error. I'm not
sure if I've found a new bug or not. In the following code, it will compile
cleanly if I put a return statement inside function template `a`, or if I
replace the return type with the simpler (non-decltype) version that is
currently commented out. Otherwise it crashes with
unexpected expression ‘i’ of kind template_parm_index
~/prefix-gcc-4.9.3/bin/g++ -std=c++11 -Wall -Wextra
templateint i
struct int_c {
static
constexpr int value = i;
};
templateint... c
struct Pack {
};
templateint... i
static
auto a() -
Pack decltype(int_ci()) :: value ...
//Pack int_ci :: value ...
{
}
int main() {
a0();
}
[Bug libfortran/66861] [5/6 Regression] Segmentation fault in gcc/testsuite/gfortran.dg/streamio_5.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66861 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-07-13 Ever confirmed|0 |1 --- Comment #2 from Janne Blomqvist jb at gcc dot gnu.org --- Hmm, does the following patch fix it? diff --git a/libgfortran/io/unix.c b/libgfortran/io/unix.c index e5fc6e1..0048e24 100644 --- a/libgfortran/io/unix.c +++ b/libgfortran/io/unix.c @@ -1570,7 +1570,7 @@ find_file0 (gfc_unit *u, FIND_FILE0_DECL) } else # endif -if (strcmp (u-filename, path) == 0) +if (u-filename strcmp (u-filename, path) == 0) return u; #endif (Sorry, I don't have a windows machine to test on myself..)
[Bug libfortran/66861] [5/6 Regression] Segmentation fault in gcc/testsuite/gfortran.dg/streamio_5.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66861 --- Comment #3 from Janne Blomqvist jb at gcc dot gnu.org --- Or rather, also fixing another similar potential issue, you might instead want to test this: diff --git a/libgfortran/io/unix.c b/libgfortran/io/unix.c index e5fc6e1..a1ce9a3 100644 --- a/libgfortran/io/unix.c +++ b/libgfortran/io/unix.c @@ -1525,7 +1525,10 @@ compare_file_filename (gfc_unit *u, const char *name, int len) goto done; } # endif - ret = (strcmp(path, u-filename) == 0); + if (u-filename) +ret = (strcmp(path, u-filename) == 0); + else +ret = 0; #endif done: free (path); @@ -1570,7 +1573,7 @@ find_file0 (gfc_unit *u, FIND_FILE0_DECL) } else # endif -if (strcmp (u-filename, path) == 0) +if (u-filename strcmp (u-filename, path) == 0) return u; #endif
[Bug c/66842] libatomic uses multiple locks for locked atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66842 --- Comment #2 from Bin Fan bin.x.fan at oracle dot com --- I couldn't find a category for libatomic, and my understand is that C and C++ share libatomic library. (In reply to Jonathan Wakely from comment #1) This obviously isn't a libstdc++ bug because you're not even using C++!
[Bug c/66842] libatomic uses multiple locks for locked atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66842 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Yes, so either C or C++ might be appropriate, but not libstdc++.
[Bug fortran/66860] [5/6 Regression] FAIL: gfortran.dg/graphite/pr42393.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66860 ktkachov at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.4 Summary|]FAIL: |[5/6 Regression] FAIL: |gfortran.dg/graphite/pr4239 |gfortran.dg/graphite/pr4239 |3.f90 -O (internal compiler |3.f90 -O (internal compiler |error) |error) Known to fail||5.1.0, 6.0 --- Comment #1 from ktkachov at gcc dot gnu.org --- The top of the gdb backtrace looks like this: Program received signal SIGSEGV, Segmentation fault. 0x7759dc90 in __GI___libc_malloc (bytes=8) at malloc.c:2924 2924malloc.c: No such file or directory. (gdb) bt #0 0x7759dc90 in __GI___libc_malloc (bytes=8) at malloc.c:2924 #1 0x0123bad9 in __gmp_default_allocate () #2 0x01221695 in __gmpz_init () #3 0x011add83 in isl_seq_elim () #4 0x0116abc3 in eliminate_var_using_equality () #5 0x0116cc11 in isl_basic_map_gauss () #6 0x0116d6f9 in isl_basic_map_simplify () #7 0x011545f0 in isl_basic_map_intersect () #8 0x011281f5 in domain_follows_at_depth () #9 0x011bf889 in isl_tarjan_components () #10 0x011bfaf0 in isl_tarjan_graph_init () #11 0x011a5576 in isl_basic_set_list_foreach_scc () #12 0x0112a349 in generate_sorted_domains () #13 0x0112b804 in add_nodes () #14 0x011a57c1 in isl_basic_set_list_foreach_scc () #15 0x0112a349 in generate_sorted_domains () #16 0x0112b804 in add_nodes () #17 0x011a57c1 in isl_basic_set_list_foreach_scc () #18 0x0112a349 in generate_sorted_domains () #19 0x0112b804 in add_nodes () #20 0x011a57c1 in isl_basic_set_list_foreach_scc () #21 0x0112a349 in generate_sorted_domains () #22 0x0112b804 in add_nodes () #23 0x011a57c1 in isl_basic_set_list_foreach_scc () #24 0x0112a349 in generate_sorted_domains () #25 0x0112b804 in add_nodes () #26 0x011a57c1 in isl_basic_set_list_foreach_scc () #27 0x0112a349 in generate_sorted_domains () #28 0x0112b804 in add_nodes () #29 0x011a57c1 in isl_basic_set_list_foreach_scc () #30 0x0112a349 in generate_sorted_domains () #31 0x0112b804 in add_nodes () #32 0x011a57c1 in isl_basic_set_list_foreach_scc () So it seems to be trying to allocate too much memory. This compiles fine on the 4.9 branch The options used are -O2 -fgraphite-identity -fno-loop-block -fno-loop-interchange -fno-loop-strip-mine
[Bug c/66862] OpenMP SIMD does not work (use SIMD instructions) on conditional code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66862 --- Comment #1 from William Jordan bill.jordan at intel dot com --- Created attachment 35972 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35972action=edit Disassembled code Assembly shows that code generated with #pragma omp simd is the same as without when the for loop contains an if statement. Without the if statement, the #pragma omp simd uses SIMD operations seen in not_floyds_w_omp_simd function.
[Bug fortran/66860] [5/6 Regression] FAIL: gfortran.dg/graphite/pr42393.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66860 --- Comment #2 from Andreas Schwab sch...@linux-m68k.org --- Stack overflow?
[Bug libfortran/66861] [5/6 Regression] Segmentation fault in gcc/testsuite/gfortran.dg/streamio_5.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66861 --- Comment #1 from Rainer Emrich rai...@emrich-ebersheim.de --- I suspect the following commit causing the issue: 215307: File size: 43008 byte(s) PR libfortran/62768 Handle filenames with embedded null characters. testsuite ChangeLog: 2014-09-17 Janne Blomqvist j...@gcc.gnu.org PR libfortran/62768 * gfortran.dg/filename_null.f90: New test. libgfortran ChangeLog: 2014-09-17 Janne Blomqvist j...@gcc.gnu.org PR libfortran/62768 * io/io.h (gfc_unit): Store C string for the filename. * io/close.c (st_close): Use gfc_unit.filename. * io/inquire.c (inquire_via_unit): Likewise. * io/open.c (new_unit): Likewise. (already_open): Likewise, unlink file before freeing filename. * io/unit.c (init_units): Likewise. (close_unit_1): Likewise. (filename_from_unit): Likewise. * io/unix.c (compare_file_filename): Likewise. (find_file0): Likewise. (delete_file): Likewise.
[Bug c/66862] New: OpenMP SIMD does not work (use SIMD instructions) on conditional code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66862
Bug ID: 66862
Summary: OpenMP SIMD does not work (use SIMD instructions) on
conditional code
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bill.jordan at intel dot com
Target Milestone: ---
Created attachment 35971
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35971action=edit
SIMD sample code
In the following loop,the omp simd pragma has no affect:
#pragma omp simd private(value) linear(ij, kj) safelen(64)
for (j = 0; j switches; ++j) {
value = cost[ik] + cost[kj];
if (value cost[ij]) {
cost[ij] = value;
}
++ij; ++kj;
}
Without the if clause, the compiler will generate SIMD code.
Compilation line is:
gcc -Wall -Wextra -O3 -save-temps -fopenmp-simd -c floyds_simd.c
Attached source includes 4 routines:
floyds_wo_omp_simd: Base function.
floyds_w_omp_simd: Base function with #pragma omp simd directive
not_floyds_wo_omp_simd: Base function without if clause
not_floyds_w_omp_simd: Base function without if clause with #pragma omp simd
[Bug fortran/52846] [F2008] Support submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846 --- Comment #8 from Salvatore Filippone sfilippone at uniroma2 dot it --- (In reply to Paul Thomas from comment #7) Created attachment 35926 [details] A partially cooked patch to complete the implentation of submodules The attached is a first attempt to complete the submodule implementation such that private entities are correctly dealt with. There are two parts to the patch: (i) Modifications to the front end to write a second half to the module files, which contains all the information about the private entities in the module. This is the bulk of the patch; and (ii) A change in the way that declarations of private entities are handled in trans-decl.c. This follows a suggestion from Richard Biener to use a technique borrowed from g++. In this patch it is only applied to variables. Cheers Paul Seems to work for my codes. I am not completely happy with the fact that a change in the PRIVATE entities will cause a change of the .mod file; it may be argued that changes are more likely to occur in the submodules than in the main module, but still, this is not 100% satisfactory wrt the advertisement that submodules are ssolving the compilation cascade problem. From a user's point of view, I do not see a good solution to this; if the .mod file contains any kind of timestamp, it's going to change anyway, even in the case where the PRIVATE part is written to a separate file. On a relate note, the point raised in the mailing list about protecting trade secrets by putting them in the PRIVATE parts is IMHO moot: if I really wanted to protect trade secrets, I would put them in a separate module that is only ever USEd by the implementation files of the user visible module, files of which I only distribute the object code. I don't think that C++ is any different in this respect. Salvatore
[Bug libfortran/66861] New: [5/6 Regression] Segmentation fault in gcc/testsuite/gfortran.dg/streamio_5.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66861 Bug ID: 66861 Summary: [5/6 Regression] Segmentation fault in gcc/testsuite/gfortran.dg/streamio_5.f90 Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: rai...@emrich-ebersheim.de Target Milestone: --- Since gcc-5 I get a lot of fortran testsuite failures. Most of these with IO involved and causing a timeout. This an regression. For trunk I'm not sure. I haven't had the time to build trunk yet. But I expect it has the same issue. $ gfortran.exe -v Es werden eingebaute Spezifikationen verwendet. COLLECT_GCC=D:\opt\devel\gnu\gcc\MINGW_NT\x86_64-w64-mingw32\mingw-w64-runtime-trunk-svn\gcc-5.1.1\bin\gfortran.exe COLLECT_LTO_WRAPPER=d:/opt/devel/gnu/gcc/mingw_nt/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.1.1/bin/../libexec/gcc/x86_64-w64-mingw32/5.1.1/lto-wrapper.exe Ziel: x86_64-w64-mingw32 Konfiguriert mit: ../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.1.1/configure --prefix=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.1.1 --with-gnu-as --with-as=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.1.1/bin/as --with-gnu-ld --with-ld=/opt/devel/gnu/gcc/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.1.1/bin/ld --build=x86_64-w64-mingw32 --enable-threads=posix --enable-languages=c,ada,c++,fortran,java,lto,objc,obj-c++ --with-gmp-include=/opt/devel/SCRATCH/tmp.kzqcdNeWDQ/install/include --with-gmp-lib=/opt/devel/SCRATCH/tmp.kzqcdNeWDQ/install/lib64 --with-mpfr-include=/opt/devel/SCRATCH/tmp.kzqcdNeWDQ/install/include --with-mpfr-lib=/opt/devel/SCRATCH/tmp.kzqcdNeWDQ/install/lib64 --with-mpc-include=/opt/devel/SCRATCH/tmp.kzqcdNeWDQ/install/include --with-mpc-lib=/opt/devel/SCRATCH/tmp.kzqcdNeWDQ/install/lib64 --with-isl-include=/opt/devel/SCRATCH/tmp.kzqcdNeWDQ/install/include --with-isl-lib=/opt/devel/SCRATCH/tmp.kzqcdNeWDQ/install/lib64 --with-local-prefix=/opt/devel/tec/devel/MINGW_NT/x86_64-w64-mingw32/mingw-w64-runtime-trunk-svn/gcc-5.1.1 --enable-libgomp --enable-fully-dynamic-string --disable-multilib --enable-checking=release --disable-werror --with-sysroot=/x86_64-w64-trunk Thread-Modell: posix gcc-Version 5.1.1 20150712 [gcc-5-branch revision 225722] (GCC) gfortran.exe -O2 /opt/devel/gnu/src/gcc/gcc-5-svn/gcc/testsuite/gfortran.dg/streamio_5.f90 $ gdb a.exe GNU gdb (GDB) 7.9 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-w64-mingw32. Type show configuration for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type help. Type apropos word to search for commands related to word... Reading symbols from a.exe...done. (gdb) run Starting program: D:\msys64\home\rainer\temp\a.exe [New Thread 4676.0x529c] Program received signal SIGSEGV, Segmentation fault. 0x07fefd675960 in strcmp () from C:\Windows\system32\msvcrt.dll (gdb) where #0 0x07fefd675960 in strcmp () from C:\Windows\system32\msvcrt.dll #1 0x6f6eaa94 in find_file0 (u=optimized out, id=id@entry=162129586587129478, path=path@entry=0x786300 teststream) at ../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.1.1/libgfortran/io/unix.c:1573 #2 0x6f6c9209 in _gfortrani_find_file (file=optimized out, file_len=optimized out) at ../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.1.1/libgfortran/io/unix.c:1615 #3 0x6f6cf385 in _gfortrani_new_unit (opp=opp@entry=0x22fc10, u=u@entry=0x785ff0, flags=flags@entry=0x22fb80) at ../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.1.1/libgfortran/io/open.c:486 #4 0x6f6bd922 in already_open (flags=optimized out, u=optimized out, opp=optimized out) at ../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.1.1/libgfortran/io/open.c:672 #5 _gfortran_st_open (opp=0x22fc10) at ../../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.1.1/libgfortran/io/open.c:837 #6 0x0040179c in MAIN__ () #7 0x00403080 in main () (gdb) exit Undefined command: exit. Try help. (gdb) quit A debugging session is active. Inferior 1 [process 4676] will be killed. Quit anyway? (y or n) [answered Y; input not from terminal] So, the crash appears in msvcrt.dll. But the call looks suspicious: find_file0 (u=optimized out, id=id@entry=162129586587129478,
[Bug tree-optimization/66846] parloops does not always mark loops for fixup if needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66846 --- Comment #1 from vries at gcc dot gnu.org --- Created attachment 35970 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35970action=edit Tentative patch
[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Jason Merrill from comment #8) I think we should reconsider the rule against partial specialization of a variable concept, as that seems like the right way to handle this situation. Except that would still run into the DR 1430 issue: a requires-clause that uses a pack expansion would normalize using the primary template defined with a parameter pack, even if a later instantiation of that requires-clause would work better with a different partial specialization.
[Bug c++/65186] internal compiler error: in tsubst, at cp/pt.c:11738
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65186 --- Comment #13 from Patrick Palka ppalka at gcc dot gnu.org --- Author: ppalka Date: Mon Jul 13 20:35:53 2015 New Revision: 225749 URL: https://gcc.gnu.org/viewcvs?rev=225749root=gccview=rev Log: Fix PR c++/65186 gcc/cp/ChangeLog: PR c++/65186 * pt.c (invalid_nontype_parm_type_p): Accept a bound template template parm type under C++11 and later. gcc/testsuite/ChangeLog: PR c++/65186 * g++.dg/template/pr65186.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/pr65186.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/66855] codecvt wrong endianness in UTF-16 conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66855 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Mon Jul 13 20:07:48 2015 New Revision: 225748 URL: https://gcc.gnu.org/viewcvs?rev=225748root=gccview=rev Log: PR libstdc++/66855 * src/c++11/codecvt.cc (__codecvt_utf8_utf16_base::do_in): Override endianness bit in mode. * testsuite/22_locale/codecvt/codecvt_utf8_utf16/66855.cc: New. Added: trunk/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf8_utf16/66855.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++11/codecvt.cc
[Bug libstdc++/66855] codecvt wrong endianness in UTF-16 conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66855 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.3 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed on trunk so far.
[Bug c++/66834] [concepts] concept parameter kind mismatch causes hard error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66834 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org --- I think we should reconsider the rule against partial specialization of a variable concept, as that seems like the right way to handle this situation.
[Bug fortran/66860] New: ]FAIL: gfortran.dg/graphite/pr42393.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66860 Bug ID: 66860 Summary: ]FAIL: gfortran.dg/graphite/pr42393.f90 -O (internal compiler error) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org Target Milestone: --- Target: aarch64-none-linux-gnu, arm-none-linux-gnueabihf This testcase takes a long time to compile and eventually ICEs
[Bug tree-optimization/66726] missed optimization, factor conversion out of COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66726 --- Comment #11 from kugan at gcc dot gnu.org --- Thanks for reporting. This test case is valid for targets that has branch cost greater than 1. One way to handle this is by disabling this for convections involving bool that are part of branch (?) I think the real fix is to make tree-ssa-reassoc handle this? Looking into it.
[Bug c++/66857] [5/6 Regression] Reference not bound to lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66857 Patrick Palka ppalka at gcc dot gnu.org changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #4 from Patrick Palka ppalka at gcc dot gnu.org --- Reverting the change made to ocp_convert in r217814 fixes it: diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c index 13bc1f7..6d4bd9a 100644 --- a/gcc/cp/cvt.c +++ b/gcc/cp/cvt.c @@ -687,7 +687,8 @@ ocp_convert (tree type, tree expr, int convtype, int flags, } /* FIXME remove when moving to c_fully_fold model. */ - e = scalar_constant_value (e); + if (!CLASS_TYPE_P (type)) +e = scalar_constant_value (e); if (error_operand_p (e)) return error_mark_node;
[Bug target/65249] unable to find a register to spill in class 'R0_REGS' when compiling protobuf on sh4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249
--- Comment #19 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
Although this is essentially a problem with the old reload, I'm testing
another adhoc patch which is hinted by an Oleg's patch for gbr addressing.
The problematic insn is (set (DImode R0) (DImode reg for return value))
originally. The subreg lowering pass splits it to two SImode move's:
(set (SImode R0) (SImode reg for the first word of return value))
(set (SImode R1) (SImode reg for the second word of return value))
The ICE happens on the latter insn because R0 is live there and the source
is replaced by memory with index addressing afterwards. The patch below
pre-splits the original DImode move in the reversed order when generating.
It also produces a bit better code for the test case even when -mlra
is specified. I intentionally limit this pre-splitting with pseudo reg
sources. If not, I've got some wired ICEs with too complex subreg rtl
in building gcc. I think that almost use of R0 destination is the above
pseudo reg for retval source and limiting it to that case would be
not a problem.
* config/sh/sh.md (movdi): Split simple reg move to two movsi
when the destination is R0.
--- ../../ORIG/trunk/gcc/config/sh/sh.md2015-07-08 10:04:22.0
+0900
+++ config/sh/sh.md 2015-07-13 11:09:43.028613182 +0900
@@ -7892,6 +7892,24 @@ label:
{
prepare_move_operands (operands, DImode);
+ if (TARGET_SH1)
+{
+ /* When the dest operand is (R0, R1) register pair, split it to
+two movsi of which dest is R1 and R0 so as to lower R0-register
+pressure on the first movsi. Apply only for simple source not
+to make complex rtl here. */
+ if (REG_P (operands[0])
+ REGNO (operands[0]) == R0_REG
+ REG_P (operands[1])
+ REGNO (operands[1]) = FIRST_PSEUDO_REGISTER)
+ {
+ emit_insn (gen_movsi (gen_rtx_REG (SImode, R1_REG),
+ gen_rtx_SUBREG (SImode, operands[1], 4)));
+ emit_insn (gen_movsi (gen_rtx_REG (SImode, R0_REG),
+ gen_rtx_SUBREG (SImode, operands[1], 0)));
+ DONE;
+ }
+}
})
(define_insn movdf_media
[Bug tree-optimization/66726] missed optimization, factor conversion out of COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66726 --- Comment #10 from Jeffrey A. Law law at redhat dot com --- Sinking the cast changes the form of the range tests into one that tree-ssa-reassoc isn't prepared to handle. Sadly the form presented with the cast sunk is *simpler* than the original. I'm testing a bit of a hack to avoid the sinking of the cast in cases where doing so is less likely to be a win.
[Bug libfortran/66861] [5/6 Regression] Segmentation fault in gcc/testsuite/gfortran.dg/streamio_5.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66861 --- Comment #4 from Rainer Emrich rai...@emrich-ebersheim.de --- Am 13.07.2015 um 20:56 schrieb jb at gcc dot gnu.org: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66861 --- Comment #3 from Janne Blomqvist jb at gcc dot gnu.org --- Or rather, also fixing another similar potential issue, you might instead want to test this: diff --git a/libgfortran/io/unix.c b/libgfortran/io/unix.c index e5fc6e1..a1ce9a3 100644 --- a/libgfortran/io/unix.c +++ b/libgfortran/io/unix.c @@ -1525,7 +1525,10 @@ compare_file_filename (gfc_unit *u, const char *name, int len) goto done; } # endif - ret = (strcmp(path, u-filename) == 0); + if (u-filename) +ret = (strcmp(path, u-filename) == 0); + else +ret = 0; #endif done: free (path); @@ -1570,7 +1573,7 @@ find_file0 (gfc_unit *u, FIND_FILE0_DECL) } else # endif -if (strcmp (u-filename, path) == 0) +if (u-filename strcmp (u-filename, path) == 0) return u; #endif I will test this tomorrow.
[Bug target/58066] __tls_get_addr is called with misaligned stack on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 --- Comment #11 from Uroš Bizjak ubizjak at gmail dot com --- Please make 64bit TLS patterns dependant on SP_REG, in the same way as 32bit are.
[Bug tree-optimization/66828] [5/6 Regression] gcc/tree-ssa-math-opts.c:2182:38: runtime error: left shift of 72057594037927936 by 8 places cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66828 Thomas Preud'homme thopre01 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-07-13 Ever confirmed|0 |1 --- Comment #1 from Thomas Preud'homme thopre01 at gcc dot gnu.org --- I'm having trouble to reproduce the bug. I do encounter some ubsan errors but in other files (most notably in hwint.h). This might hide the errors in tree-ssa-math-opts.c Anyway, according to the line number the issue seems to come from the following line: for (i = 0; i size; i++, inc = BITS_PER_MARKER) size is guaranteed to be less or equal to 64 / BITS_PER_MARKER as per checks in find_bswap_or_nop_1 (CASE_CONVERT) and in init_symbolic_number. However, this means after the last execution of the body, inc is shift by more than 63 bits in total. I'm now testing a patch via bootstrap + regression testsuite.
[Bug c/66853] New: sanitized gcc shows bug in rtlanal.c:4911 shift exponent too large because bitwitdth==0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66853
Bug ID: 66853
Summary: sanitized gcc shows bug in rtlanal.c:4911 shift
exponent too large because bitwitdth==0
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Target Milestone: ---
This appears to be a duplicate for 64327
Sanitized version of gcc 5.1.0 shows a bug in the following
/* from gcc file fixopts.c */
/* must be compiled with -O2 */
/*gcc-5.1.0/gcc/rtlanal.c:4911:48: runtime error: shift exponent 4294967295 is
too large for 64-bit type 'long unsigned int'*/
/*on source line return nonzero ((unsigned HOST_WIDE_INT) 1 (bitwidth -
1))*/
/* because unsigned int bitwidth is zero and bitwitdth-1 is 4294967295 on my
x86-64 */
/* I did double check with:
* bitwidth = GET_MODE_PRECISION (mode);
* gcc_assert(bitwidth);
*/
/* the bug appears compiling fixopts.c crc32.c md5.c and many Fedora 21 kernel
files*/
int strcmp(const char *s1, const char *s2);
int fixinc_mode; /* must be outside main for bug to appear */
int main (void)
{
const char *pz;
if (strcmp (pz, true) ) fixinc_mode = 0;
}
[Bug lto/66752] spec2000 255.vortex performance compiled with GCC is ~20% lower than with CLANG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66752 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-13 CC||law at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- This is simply a jump-threading opportunity that is not taken (with the complication that this threads through the loop header). I wonder whether the FSM thereading machiner could catch this though.
[Bug middle-end/64327] ../../gcc/gcc/rtlanal.c:4881:48: runtime error: shift exponent 4294967295 is too large for 64-bit type 'long unsigned int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64327 Vittorio Zecca zeccav at gmail dot com changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #2 from Vittorio Zecca zeccav at gmail dot com --- Please see bug 66853, it appears to duplicate this one. With a small reproducer included.
[Bug c/66853] sanitized gcc shows bug in rtlanal.c:4911 shift exponent too large because bitwitdth==0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66853 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- dup. *** This bug has been marked as a duplicate of bug 64327 ***
[Bug middle-end/64327] ../../gcc/gcc/rtlanal.c:4881:48: runtime error: shift exponent 4294967295 is too large for 64-bit type 'long unsigned int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64327 --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 66853 has been marked as a duplicate of this bug. ***
[Bug driver/66849] Incorrect multilib chosen with -mthumb -mfloat-abi=hard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66849
--- Comment #1 from simon at pushface dot org ---
I should have said, I’m interested in Cortex-M3 and Cortex-M4{F); and possibly
Cortex-M7(F).
[Bug rtl-optimization/66556] Wrong code-generation for armv7-a big-endian at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66556 --- Comment #3 from renlin at gcc dot gnu.org --- Author: renlin Date: Mon Jul 13 08:29:46 2015 New Revision: 225729 URL: https://gcc.gnu.org/viewcvs?rev=225729root=gccview=rev Log: [PATCH]Fix PR66556. Don't drop side-effect in simplify_const_relational_operation function. gcc/ 2015-07-13 Renlin Li renlin...@arm.com PR rtl/66556 * simplify-rtx.c (simplify_const_relational_operation): Add side_effects_p checks. gcc/testsuite/ 2015-07-13 Renlin Li renlin...@arm.com PR rtl/66556 * gcc.c-torture/execute/pr66556.c: New. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr66556.c Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c trunk/gcc/testsuite/ChangeLog
