[Bug bootstrap/66521] xgcc: cc1plus segfaults when compiling libstdc++-v3/src/c++11/ostream-inst.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66521 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Eric Gallager from comment #2) (CC-ing someone on a bug doesn't count as contacting them directly, right? Just making sure I'm not violating that line from MAINTAINERS...) Right, you did the right thing, thanks.
[Bug bootstrap/66521] xgcc: cc1plus segfaults when compiling libstdc++-v3/src/c++11/ostream-inst.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66521 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Eric Gallager from comment #5) this one; I think I had to pass the '--disable-libstdcxx-filesystem-ts' flag to configure last time to get past it... I'll open a new PR about it. Please do, I'm planning to backport the Filesystem TS for GCC 5.3 so if it breaks the bootstrap on darwin I'd like to know the details.
[Bug fortran/65766] gFortran Compiler SEGFAULTING on compiling simple program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65766 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- The patch in comment 3 fixes the PR without regression, as well as pr61676, pr63494, and pr66562 (duplicates?). Note that patches should be posted to gcc-patc...@gcc.gnu.org and for gfortran to fort...@gcc.gnu.org with the change log entry.
[Bug bootstrap/67066] libstdc++-v3/src/filesystem/dir.cc fails to compile, preventing bootstrapping with libstdcxx-filesystem-ts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67066 --- Comment #1 from Eric Gallager egall at gwmail dot gwu.edu --- Created attachment 36092 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36092action=edit (compressed) preprocessed source
[Bug c++/67065] Missing diagnostics for ill-formed program with main variable instead of function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67065 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-30 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Anders Granlund from comment #0) The following program is ill-formed (proc.cc): int main; Compile it with the following command line: clang++ prog.cc -std=c++14 -pedantic-errors Erm :-) It fails with G++ too though.
[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002 --- Comment #11 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to John Paul Adrian Glaubitz from comment #10) Looking at the build log, it's only gcc/real.o where the comparison fails, all the others (except for the checksum files) are find. I think chances are that, if this is actually a real bug, it might show itself more pronounced when we use gcc-5 to build other packages. Just look at how many bugs we were able to find in gcc-4.9 while using it as the standard host compiler on Debian sh4. Yeah, for this purpose it can be ignored of course. However, I guess for that you might also just disable bootstrapping (configure with --disable-bootstrap).
[Bug bootstrap/67066] New: libstdc++-v3/src/filesystem/dir.cc fails to compile, preventing bootstrapping with libstdcxx-filesystem-ts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67066 Bug ID: 67066 Summary: libstdc++-v3/src/filesystem/dir.cc fails to compile, preventing bootstrapping with libstdcxx-filesystem-ts Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: egall at gwmail dot gwu.edu Target Milestone: --- Host: x86_64-apple-darwin10.8.0 Target: x86_64-apple-darwin10.8.0 Build: x86_64-apple-darwin10.8.0 Created attachment 36091 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36091action=edit compiler error output The error messages are kind of long, so I'll be attaching them. My version info: $ /Users/ericgallager/gcc-git/my_oddly_named_builddir/./gcc/xgcc -v Using built-in specs. COLLECT_GCC=/Users/ericgallager/gcc-git/my_oddly_named_builddir/./gcc/xgcc Target: x86_64-apple-darwin10.8.0 Configured with: ../configure --enable-libada --enable-libssp --enable-bootstrap --enable-lto --enable-stage1-languages=all --enable-objc-gc --enable-vtable-verify --enable-maintainer-mode --disable-werror --enable-host-shared --enable-languages=c,c++,java,jit,lto,objc,obj-c++ --enable-stage1-checking=all --enable-libstdcxx-time -C --enable-multilib --enable-multiarch --enable-__cxa_atexit --enable-tls --with-system-libunwind --enable-secureplt --enable-frame-pointer --enable-version-specific-runtime-libs --enable-plugin --enable-cxx --enable-assert --enable-fat --enable-portable-binary --enable-browser-plugin --enable-gconf-peer --enable-libgcj-debug --enable-gc-debug --enable-interpreter --enable-aot-compile-rpm --enable-java-home --with-x --enable-collections --enable-gstreamer-peer --enable-xmlj --enable-qt-peer --enable-gmp --enable-debug --enable-local-sockets --enable-concept-checks --without-isl AUTOCONF=autoconf264 AUTOHEADER=autoheader264 AUTOM4TE=autom4te264 AUTORECONF=autoreconf264 AUTOSCAN=autoscan264 AUTOUPDATE=autoupdate264 IFNAMES=ifnames264 Thread model: posix gcc version 6.0.0 20150604 (experimental) (GCC) Passing the '--disable-libstdcxx-filesystem-ts' flag (and some less-strict stage1-checking options) to configure allows the build to proceed past this point.
[Bug bootstrap/66521] xgcc: cc1plus segfaults when compiling libstdc++-v3/src/c++11/ostream-inst.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66521 --- Comment #8 from Eric Gallager egall at gwmail dot gwu.edu --- (In reply to Jonathan Wakely from comment #7) (In reply to Eric Gallager from comment #5) this one; I think I had to pass the '--disable-libstdcxx-filesystem-ts' flag to configure last time to get past it... I'll open a new PR about it. Please do, I'm planning to backport the Filesystem TS for GCC 5.3 so if it breaks the bootstrap on darwin I'd like to know the details. Okay, I've opened Bug 67066 for that. Although, after getting past that one, I'm back to something that looks at least semi-libvtv-related: /bin/sh ../libtool --tag CXX --mode=link /Users/ericgallager/gcc-git/my_oddly_named_builddir/./gcc/xgcc -shared-libgcc -B/Users/ericgallager/gcc-git/my_oddly_named_builddir/./gcc -nostdinc++ -L/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/src -L/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -L/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-apple-darwin10.8.0/bin/ -B/usr/local/x86_64-apple-darwin10.8.0/lib/ -isystem /usr/local/x86_64-apple-darwin10.8.0/include -isystem /usr/local/x86_64-apple-darwin10.8.0/sys-include -L/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/../libvtv/.libs -Wl,--rpath -Wl,/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/../libvtv/.libs -Wl,-single_module -std=gnu++98 -fno-common -DPIC -fno-implicit-templates -fvtable-verify=std -Wl,-u_vtable_map_vars_start,-u_vtable_map_vars_end -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -fvisibility-inlines-hidden -ffunction-sections -fdata-sections -frandom-seed=libstdc++.la -o libstdc++.la -version-info 6:22:0 -Wl,-exported_symbols_list,libstdc++-symbols.explist -lm -rpath /usr/local/lib/gcc/x86_64-apple-darwin10.8.0/6.0.0 compatibility.lo compatibility-debug_list.lo compatibility-debug_list-2.lo compatibility-c++0x.lo compatibility-atomic-c++0x.lo compatibility-thread-c++0x.lo compatibility-chrono.lo compatibility-condvar.lo ../libsupc++/libsupc++convenience.la ../src/c++98/libc++98convenience.la ../src/c++11/libc++11convenience.la libtool: link: /Users/ericgallager/gcc-git/my_oddly_named_builddir/./gcc/xgcc -shared-libgcc -B/Users/ericgallager/gcc-git/my_oddly_named_builddir/./gcc -nostdinc++ -L/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/src -L/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -L/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-apple-darwin10.8.0/bin/ -B/usr/local/x86_64-apple-darwin10.8.0/lib/ -isystem /usr/local/x86_64-apple-darwin10.8.0/include -isystem /usr/local/x86_64-apple-darwin10.8.0/sys-include-dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libstdc++.6.dylib .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o -Wl,-force_load,../libsupc++/.libs/libsupc++convenience.a -Wl,-force_load,../src/c++98/.libs/libc++98convenience.a -Wl,-force_load,../src/c++11/.libs/libc++11convenience.a -L/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/libsupc++/.libs -L/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/src -L/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -L/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/../libvtv/.libs -lm -Wl,--rpath -Wl,/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/../libvtv/.libs -Wl,-single_module -Wl,-u_vtable_map_vars_start -Wl,-u_vtable_map_vars_end -Wl,-exported_symbols_list -Wl,libstdc++-symbols.explist -install_name /usr/local/lib/gcc/x86_64-apple-darwin10.8.0/6.0.0/libstdc++.6.dylib -compatibility_version 7 -current_version 7.22 -Wl,-single_module ld: warning: directory not found for option '-L/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/../libvtv/.libs' ld: unknown option: --rpath collect2: error: ld returned 1 exit status make[6]: *** [libstdc++.la] Error 1 make[6]: Leaving directory `/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/src' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/Users/ericgallager/gcc-git/my_oddly_named_builddir/x86_64-apple-darwin10.8.0/libstdc++-v3/src' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory
[Bug tree-optimization/66917] [4.9/5/6 regression] ARM: NEON: memcpy compiles to vst1 with incorrect alignment due to SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Component|target |tree-optimization --- Comment #12 from Richard Earnshaw rearnsha at gcc dot gnu.org --- but the arm hook seems to say yes, I can vectorize with V2DImode for a vector with element type unsigned long long __attribute__((aligned(1))) which it obviously cannot. It can vectorize for this case, but the loads must not be marked as aligned loads. That is, the mid-end must use the misaligned code hooks. So I don't think this is a target bug.
[Bug target/57271] ARM: gcc generates insufficient alignment for memory passed as extra argument for function return large composite type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57271 --- Comment #11 from Mark H Weaver mhw at netris dot org --- FYI, there's now a suggested fix for bug #66917. It would be interesting to know whether it fixes the problem reported here.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 hannes_weisbach at gmx dot net changed: What|Removed |Added CC||hannes_weisbach at gmx dot net --- Comment #4 from hannes_weisbach at gmx dot net --- Hi, I've read the bug report and dug into the standards. This is my understanding of the issue(s): Quoting N3337 and N3797 (C++11 14 Standard Drafts) §7.1.1/2 (dcl.stc): The register specifier shall be applied only to names of variables declared in a block (6.3) or to function parameters (8.4). So gcc should reject the declaration of 'reg' outright, since it is not declared inside a block and 'reg' is not a function parameter. If 'reg' would be properly declared, namely in block scope, the note (though non-normative) in §7.1.1/3 (dcl.stc) is interesting: The hint can be ignored and in most implementations it will be ignored if the address of the variable is taken. (Which is the case by enclosing it in braces, see below.) As for the type of '(expression)' §5.1.1/6 (expr.prim.general) says: A parenthesized expression is a primary expression whose type and value are identical to those of the enclosed expression. The presence of parentheses does not affect whether the expression is an lvalue. The parenthesized expression can be used in exactly the same contexts as those where the enclosed expression can be used, and with the same meaning, except as otherwise indicated. So clearly, parenthesis should not change the type, but both clang (Apple LLVM version 6.1.0 (clang-602.0.53)) and gcc (gcc version 5.1.0 (Homebrew gcc 5.1.0)) do. Given the declaration of 'struct s' from the example, and a definition of 'struct s * reg;' (to avoid the register thing) the type of 'reg' is 's*', but the type of '(reg)' is 's*'. Since now there is a reference to 'reg', its address has been taken. OTOH, §7.1.6.2/4 says that, if e is an parenthesized expression with type T, decltype(e) is T. I would expect the type of 'reg' being different from '(reg)' only in a decltype-specifier and not otherwise. Maybe someone can explain why the decltype-rule for (the type of) parenthesized expression is applicable without the decltype-specifier there. I hope the language-lawyering brought at least some clarity.
[Bug tree-optimization/66917] [4.9/5/6 regression] ARM: NEON: memcpy compiles to vst1 with incorrect alignment due to SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
--- Comment #15 from Richard Biener rguenth at gcc dot gnu.org ---
For both loads and stores we do
else if (DR_MISALIGNMENT (first_dr) == -1)
{
TREE_TYPE (data_ref)
= build_aligned_type (TREE_TYPE (data_ref),
TYPE_ALIGN (elem_type));
align = TYPE_ALIGN_UNIT (elem_type);
misalign = 0;
but TYPE_ALIGN (elem_type) doesn't always hold.
[Bug tree-optimization/66917] [4.9/5/6 regression] ARM: NEON: memcpy compiles to vst1 with incorrect alignment due to SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917 --- Comment #14 from rguenther at suse dot de rguenther at suse dot de --- On Thu, 30 Jul 2015, rearnsha at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Component|target |tree-optimization --- Comment #12 from Richard Earnshaw rearnsha at gcc dot gnu.org --- but the arm hook seems to say yes, I can vectorize with V2DImode for a vector with element type unsigned long long __attribute__((aligned(1))) which it obviously cannot. It can vectorize for this case, but the loads must not be marked as aligned loads. That is, the mid-end must use the misaligned code hooks. So I don't think this is a target bug. Hmm, indeed. It's a vectorizer bug that always communicates at least element alignment (thus doesn't properly code-gen for the packed_p case)
[Bug c++/67067] New: #error -static-libstdc++ not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67067 Bug ID: 67067 Summary: #error -static-libstdc++ not implemented Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zclai at yahoo dot com Target Milestone: ---
[Bug fortran/67068] New: Ambiguous interfaces generated when including open mip fortran header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67068 Bug ID: 67068 Summary: Ambiguous interfaces generated when including open mip fortran header Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mwglass at sandia dot gov Target Milestone: --- Using gfortran-5.2.0 with openmpi 1.8.7 on a Linux RHEL system. When compiling a FORTRAN file with -freal-4-real-8 -fdefault-double-8 -fdefault-real-8 and having the file include the mpif.h header from openmpi, gfortran generates the following error: mpif-sizeof.h:575:41: c 'mpi_sizeof_real64_r7' and 'mpi_sizeof_real32_r7' in generic interface 'mpi_sizeof' at (1) mpif-sizeof.h:1139:42: Error: Ambiguous interfaces 'pmpi_sizeof_real64_r7' and 'pmpi_sizeof_real32_r7' in generic interface 'pmpi_sizeof' at (1) mpif-sizeof.h:575:41: Error: Ambiguous interfaces 'mpi_sizeof_real64_r7' and 'mpi_sizeof_real32_r7' in generic interface 'mpi_sizeof' at (1) mpif-sizeof.h:1139:42: Error: Ambiguous interfaces 'pmpi_sizeof_real64_r7' and 'pmpi_sizeof_real32_r7' in generic interface 'pmpi_sizeof' at (1) mpif-sizeof.h:575:41: Error: Ambiguous interfaces 'mpi_sizeof_real64_r7' and 'mpi_sizeof_real32_r7' in generic interface 'mpi_sizeof' at (1) mpif-sizeof.h:1139:42: Error: Ambiguous interfaces 'pmpi_sizeof_real64_r7' and 'pmpi_sizeof_real32_r7' in generic interface 'pmpi_sizeof' at (1) All previous versions of gfortran (4,7.x, 4.8.x, 4.9.x, 5.0, and 5.1) did not do this. This also has never been a issue with the Intel fortran compile v14.x and 15.x.
[Bug tree-optimization/66917] [4.9/5/6 regression] ARM: NEON: memcpy compiles to vst1 with incorrect alignment due to SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
Daniel Gutson daniel.gutson at tallertechnologies dot com changed:
What|Removed |Added
CC||daniel.gutson@tallertechnol
||ogies.com
--- Comment #5 from Daniel Gutson daniel.gutson at tallertechnologies dot com
---
FWIW, g++ 4.8.4 and clang 3.5 do not complain in the following code:
struct s {
int i;
};
//register struct s *reg __asm__( 1 );
s* reg;
int f(void)
{
int i;
i = reg-i;
i = (reg)-i;
return i;
}
As from the same paragraphs of the standard, I don't think that a adding
parenthesis should alter the valueness type outside a decltype, meaning that
this could be an error lately introduced. I'll ask for a Committee member help
here.
[Bug c++/67067] Trouble closing elf file and -static-libstdc++ not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67067
Alex Lai zclai at yahoo dot com changed:
What|Removed |Added
Summary|#error -static-libstdc++|Trouble closing elf file
|not implemented |and -static-libstdc++ not
||implemented
--- Comment #1 from Alex Lai zclai at yahoo dot com ---
on Solaris x86, I downloaded MPC, GMP and MPFR and extracted them into GCC
source directory as mpc,gmp and mpfr directories and configure GCC source with:
$ ../gcc-5.2.0.src/configure --prefix=$HOME/gcc-5.2.0 --enable-languages=c,c++
$ gmake
I got the following error:
Assembler: optimize.c
/var/tmp//ccMndPR3.s, line 85111 : Trouble closing elf file
gmake[3]: *** [cp/optimize.o] Error 1
The file mentioned in the error message doesn’t exist.
$ ls -l /var/tmp//ccEtAJ5n.s
/var/tmp//ccEtAJ5n.s: No such file or directory
The file system has plenty of room:
$ df -h /var/tmp
Filesystem size used avail capacity Mounted on
/dev/dsk/c0t0d0s6 99G27G71G28%/var
$ uname -a
SunOS sbdsvrwm566 5.10 Generic_150401-20 i86pc i386 i86pc
the only error message in config.log is as follows:
configure:5091: g++ -o conftest -g -O2 -static-libstdc++ -static-libgcc
conftest.cpp 5
g++: unrecognized option `-static-libstdc++'
conftest.cpp:11:2: #error -static-libstdc++ not implemented
configure:5091: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME
| #define PACKAGE_TARNAME
| #define PACKAGE_VERSION
| #define PACKAGE_STRING
| #define PACKAGE_BUGREPORT
| #define PACKAGE_URL
| /* end confdefs.h. */
|
| #if (__GNUC__ 4) || (__GNUC__ == 4 __GNUC_MINOR__ 5)
| #error -static-libstdc++ not implemented
| #endif
| int main() {}
the lib exists and its path is included in lib search path:
$ ls -l /usr/local/lib/libstdc++.so
lrwxrwxrwx 1 root root 18 May 31 2012
/usr/local/lib/libstdc++.so - libstdc++.so.6.0.3
$ echo $LD_LIBRARY_PATH
/opt/SUNWspro11/SUNWspro/prod/lib:/usr/local/lib:/usr/lib:/usr/lib/X11
the error apparently is due to the missing space between -static and
-libstdc++. however,none of the mentioned confdefs.h conftest.cpp exist either
under the source or build directory or installed packages.
obviously the older gcc was used to compile the new gcc:
configure:4074: checking for gcc
configure:4090: found /usr/sfw/bin/gcc
configure:4101: result: gcc
configure:4330: checking for C compiler version
configure:4339: gcc --version 5
gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ echo $PATH
/usr/ccs/bin:/usr/bin:/usr/sfw/bin:/usr/sbin:/usr/local/bin:/opt/SUNWspro/bin:/bin:/usr/bin:/usr/sbin:/usr/ucb:/bns/bin:/usr/openwin/bin:
[Bug c++/67067] Trouble closing elf file and -static-libstdc++ not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67067 --- Comment #3 from Alex Lai zclai at yahoo dot com --- (In reply to Jonathan Wakely from comment #2) (In reply to Alex Lai from comment #1) the error apparently is due to the missing space between -static and -libstdc++. There is no missing space, that's a valid gcc option. Thanks Jonathan for the information.
[Bug fortran/67068] Ambiguous interfaces generated when including open mip fortran header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67068 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #4 from Harald Anlauf anlauf at gmx dot de --- (In reply to Mike Glass from comment #2) Yes, all the FORTRAN code is compiled with those options. We want to mimic the behavior of the Intel compiler when we add the '-r8' flag to their compiler: Makes default real and complex declarations, constants, functions, and intrinsics 8 bytes long. REAL declarations are treated as DOUBLE PRECISION (REAL(KIND=8)) and COMPLEX declarations are treated as DOUBLE COMPLEX (COMPLEX(KIND=8)). Real and complex constants of unspecified KIND are evaluated in double precision (KIND=8). Is there a reason you don't use mpi?
[Bug go/66870] split stack issues on ppc64le and ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870 --- Comment #15 from boger at us dot ibm.com --- I have submitted my patch to gcc-patches to check for the no_split_stack attribute after revising it based on Alan's comments.
[Bug c++/67070] New: [concepts] Concept with negation and disjunction not checked correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67070
Bug ID: 67070
Summary: [concepts] Concept with negation and disjunction not
checked correctly
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
Created attachment 36093
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36093action=edit
preprocessed source archive
The static assertion in the attached file fires when it shouldn't. If the
_ContainerLike concept is changed from this:
template class T
concept bool _ContainerLike =
RangeT()
Rangeconst T()
!SameReferenceTypeIteratorTypeT,
ReferenceTypeIteratorTypeconst T();
... to this:
template class T
constexpr bool __container_like() { return false; }
template Range T
requires Rangeconst T()
!SameReferenceTypeIteratorTypeT,
ReferenceTypeIteratorTypeconst T()
constexpr bool __container_like() { return true; }
template class T
concept bool _ContainerLike = __container_likeT();
... the static assertion goes away. These two seem the same to me.
[Bug c++/67007] [c++-concepts] Deduction constraint + requires expression interaction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67007 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug c++/67007] [c++-concepts] Deduction constraint + requires expression interaction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67007 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Jul 30 20:38:27 2015 New Revision: 226415 URL: https://gcc.gnu.org/viewcvs?rev=226415root=gccview=rev Log: PR c++/67007 * constraint.cc (normalize_predicate_constraint): Set processing_template_decl. (make_constrained_auto): Don't normalize here. Added: branches/c++-concepts/gcc/testsuite/g++.dg/concepts/deduction-constraint1.C Modified: branches/c++-concepts/ChangeLog.concepts branches/c++-concepts/gcc/cp/constraint.cc
[Bug rtl-optimization/67000] [6 Regression] ICE in split_complex_args, at function.c:2325 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67000 --- Comment #4 from Gary Funck gary at intrepid dot com --- (In reply to Alexandre Oliva from comment #3) The problem initially reported in this bug is now fixed in the git branch aoliva/pr64164. I'm not sure how to go about duplicating the one in comment 1, but, having fixed a number of additional split_complex issues since the patch that caused the problems was put in, I hope it's fixed too. Gary, would you please detail the toplevel configure and build command lines to trigger it, or perhaps give the branch a try and confirm that it fixes the problem? Thanks, Alexandre, The configuration command was along these lines: configure CFLAGS='-g3 -O0' CXXFLAGS='-g3 -O0' TARGET_CFLAGS='-g3 -O0' TARGET_CXXFLAGS='-g3 -O0' --enable-bootstrap=no --enable-checking=yes --enable-languages=c,c++ --disable-build-format-warnings PS: the issue did go away when merged with a later svn trunk version, consistent with Richard's comment #2.
[Bug middle-end/67034] [6 Regression] FAIL: gcc.c-torture/compile/pr39928-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67034 --- Comment #2 from dave.anglin at bell dot net --- On 2015-07-30, at 2:18 PM, aoliva at gcc dot gnu.org wrote: John, if you can help with that, would you like the asm for this one testcase, or is it easy enough for you to give the branch a round of testing? I'll give your branch a try in next round of testing, probably tomorrow. Dave -- John David Anglin dave.ang...@bell.net
[Bug rtl-optimization/67072] Slow code generated for getting each byte of a 64bit register as a LUT index.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67072 --- Comment #3 from Peter Cordes peter at cordes dot ca --- @Andrew Pinski: same code is generated with -march=sandybridge (-march=native on Sandybridge). (Except of course the intrinsics use the VEX version.) -mtune=intel doesn't help either.
[Bug rtl-optimization/67072] New: Slow code generated for getting each byte of a 64bit register as a LUT index.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67072
Bug ID: 67072
Summary: Slow code generated for getting each byte of a 64bit
register as a LUT index.
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: peter at cordes dot ca
Target Milestone: ---
gcc produces much slower code than what I wrote by hand, for a function that
does LUT lookups for each byte of source data.
intrinsics version (bad code):
https://github.com/pcordes/par2-asm-experiments/blob/master/intrin-pinsrw.c
hand-written asm version (good code):
https://github.com/pcordes/par2-asm-experiments/blob/master/asm-pinsrw.s
Both versions maintain two dependency chains to avoid latency bottlenecks.
My hand-written asm uses movzx from dl and dh, then shifts by 16 to bring the
next two bytes into dl/dh.
movzx %dl, %eax
movzx %dh, %ebx
shr $16, %rdx ; set up for next block of this dep
chain
pinsrw $1, 0x(%rsi, %rax, 4), %xmm0
pinsrw $1, 0x(%rdi, %rbx, 4), %xmm1
repeat for $2, etc.
Here's a cut-down version that doesn't need any extra headers:
#include emmintrin.h
#include stdint.h
union wordbytes { uint16_t w; uint8_t b[2]; };
void rs_process_pinsrw_intrin(void* dstvoid, const void* srcvoid, size_t size,
const uint32_t* LH)
{
const uint64_t *src = srcvoid;
__m128i d, l, h;
__m128i *dst = dstvoid;
for (size_t i = 0; i size/sizeof(d) ; i+=1) {
#define LO(x) ((uint8_t)x)
//#define HI(x) ((uint8_t)((x 8) 0xff))
//#define HI(x) ( (uint8_t) (((uint16_t)x) 8) ) // This gets gcc to emit
movz %bh, %eax, unlike the 0xff version
// u8(((u16) s) 8)
#define HI(x) (( (union wordbytes) ((uint16_t)x) ).b[1]) // fastest code, but
still horrible; WAY too much useless mov
uint64_t s0 = src[i*2 + 0];
uint64_t s1 = src[i*2 + 1];
l = _mm_cvtsi32_si128( LH[ LO(s0)] ); // movd
the lookup for the l/h byte of the first word
h = _mm_cvtsi32_si128( LH[256 + HI(s0)] );
s0 = 16;
l = _mm_insert_epi16(l, LH[ LO(s1)], 4);
h = _mm_insert_epi16(h, LH[256 + HI(s1)], 4);
s1 = 16;
l = _mm_insert_epi16(l, LH[ LO(s0)], 1);
h = _mm_insert_epi16(h, LH[256 + HI(s0)], 1);
s0 = 16;
l = _mm_insert_epi16(l, LH[ LO(s1)], 5);
h = _mm_insert_epi16(h, LH[256 + HI(s1)], 5);
s1 = 16;
l = _mm_insert_epi16(l, LH[ LO(s0)], 2);
h = _mm_insert_epi16(h, LH[256 + HI(s0)], 2);
s0 = 16;
l = _mm_insert_epi16(l, LH[ LO(s1)], 6);
h = _mm_insert_epi16(h, LH[256 + HI(s1)], 6);
s1 = 16;
l = _mm_insert_epi16(l, LH[ LO(s0)], 3);
h = _mm_insert_epi16(h, LH[256 + HI(s0)], 3);
l = _mm_insert_epi16(l, LH[ LO(s1)], 7);
h = _mm_insert_epi16(h, LH[256 + HI(s1)], 7);
#undef LO
#undef HI
d = _mm_xor_si128(l, h);// gcc 4.9 uses a 3rd xmm reg
for no reason, even with l instead of d
d = _mm_xor_si128(d, dst[i]);
_mm_store_si128(dst[i], d);
}
}
alias m=less
gcc -std=gnu11 -O3 -o- -S intrin-pinsrw-simple.c 21 | m
gcc 4.9.2's output for this includes a lot of extra mov instructions. Instead
of shifting s0 and s1 in the same register, it copies them to another register
and then shifts that by 16, 32, or 48. Maybe gcc would have done better if it
had decided to put s0 and s1 into registers that have a high 16 (%ah, %bh, %ch,
%dh), instead of r9 and r14.
It runs 35% slower than my hand-tuned asm version, on Intel Sandybridge. uop
throughput is the bottleneck here, because there's a mix of load and ALU uops,
and the dep chains are short enough to not be a problem. (4 fused-domain uops
per cycle). My asm version does more PINSRW xmm dep chains in parallel, and
merges at the end with punpcklqdq, but that change only gained a couple %,
IIRC.
[Bug fortran/67063] segfault in opening a formatted file at second time with status=replace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67063 --- Comment #2 from HEMMI, Shigeru textdirected at gmail dot com --- Thanks for the reply. My output of 'gfortran -v' is: PS E:\tmp gfortran -v Using built-in specs. COLLECT_GCC=E:\mingw-w64\mingw64\bin\gfortran.exe COLLECT_LTO_WRAPPER=E:/mingw-w64/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/5.1.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../../src/gcc-5.1.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64- w64-mingw32 --prefix=/mingw64 --with-sysroot=/c/mingw510/x86_64-510-posix-seh-rt_v4-rev0/mingw64 --with-gxx-include-dir =/mingw64/x86_64-w64-mingw32/include/c++ --enable-shared --enable-static --disable-multilib --enable-languages=ada,c,c+ +,fortran,objc,obj-c++,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic --ena ble-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-lib s --disable-isl-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --di sable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona -- with-tune=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw510/prerequisites/x86_64-w64-mingw32-static --wit h-mpfr=/c/mingw510/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/mingw510/prerequisites/x86_64-w64-mingw32-stat ic --with-isl=/c/mingw510/prerequisites/x86_64-w64-mingw32-static --with-pkgversion='x86_64-posix-seh-rev0, Built by Mi nGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw510/x86_64-510-pos ix-seh-rt_v4-rev0/mingw64/opt/include -I/c/mingw510/prerequisites/x86_64-zlib-static/include -I/c/mingw510/prerequisite s/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw510/x86_64-510-posix-seh-rt_v4-rev0/mingw64/opt/incl ude -I/c/mingw510/prerequisites/x86_64-zlib-static/include -I/c/mingw510/prerequisites/x86_64-w64-mingw32-static/includ e' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw510/x86_64-510-posix-seh-rt_v4-rev0/mingw64/opt/lib -L/c/mingw510/prerequisites/x 86_64-zlib-static/lib -L/c/mingw510/prerequisites/x86_64-w64-mingw32-static/lib ' Thread model: posix gcc version 5.1.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project)
[Bug rtl-optimization/67072] Slow code generated for getting each byte of a 64bit register as a LUT index.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67072 --- Comment #2 from Peter Cordes peter at cordes dot ca --- I restructured the intrinsics loop to match the asm. This gave a small speedup, but it's still ~30% slower than my asm. clang-3.5 is even slower than gcc. I still don't software-pipeline the loads in C the way I do in asm, that kind of instruction scheduling is something compilers should do, shouldn't they? Still, that shouldn't make a 30% difference. The re-order buffer should be big enough to hold the uops for a few independent iterations. https://github.com/pcordes/par2-asm-experiments/blob/d061202b69218963fdc03619be208327e03ceb71/intrin-pinsrw.c Again, timings are on an Intel Sandybridge i5-2500k, with the system mostly idle.
[Bug rtl-optimization/67072] Slow code generated for getting each byte of a 64bit register as a LUT index.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67072 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Have you tried adding -march=intel ?
[Bug fortran/67073] New: short program produces ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67073 Bug ID: 67073 Summary: short program produces ICE Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: danlnagle at me dot com Target Milestone: --- Created attachment 36094 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36094action=edit source causing ICE This was discovered when testing leading-edge features from coarrays. Program f2.f90 is the culprit. Adding -Wall gives no further clues. Here's the result: Dans-MacBook-Pro:coarrays dan$ mpif90 -fcoarray=lib f2.f90 -lcaf_mpi f2.f90:18:0: LOCK (lock2) 1 internal compiler error: in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:1812 f2.f90:18:0: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951) Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Dans-MacBook-Pro:coarrays dan$ gfortran --version GNU Fortran (GCC) 6.0.0 20150727 (experimental) Copyright (C) 2015 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING Dans-MacBook-Pro:coarrays dan$ mpif90 --version GNU Fortran (GCC) 6.0.0 20150727 (experimental) Copyright (C) 2015 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING File f2.f90 is attached. Thanks for your time and attention.
[Bug c++/67065] Missing diagnostics for ill-formed program with main variable instead of function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67065 --- Comment #3 from Anders Granlund anders.granlund.0 at gmail dot com --- (In reply to Jonathan Wakely from comment #1) (In reply to Anders Granlund from comment #0) The following program is ill-formed (proc.cc): int main; Compile it with the following command line: clang++ prog.cc -std=c++14 -pedantic-errors Erm :-) It fails with G++ too though. Lol. Don't worry, GCC is still my favourite compiler bug generator. :P
[Bug c++/67074] New: Name lookup ambiguity between namespace and its alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67074
Bug ID: 67074
Summary: Name lookup ambiguity between namespace and its alias
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Test case:
namespace P{ namespace X { static int i = 1; } }
namespace Q { namespace X = P::X; }
using namespace P;
using namespace Q;
int main() { X::i; }
Command line:
g++ prog.cc -std=c++14 -pedantic-errors
This results in name-lookup ambiguity errors when looking up X in main. This is
not a name-lookup ambiguity since the two names founds denotes the same entity.
I tried this with gcc HEAD 6.0.0 20150730 here:
http://melpon.org/wandbox/permlink/6IBZhBmgDMkq6Eho
[Bug c++/67074] Name lookup ambiguity between namespace and its alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67074
--- Comment #1 from Anders Granlund anders.granlund.0 at gmail dot com ---
I have reported the same bug in clang also:
https://llvm.org/bugs/show_bug.cgi?id=24324
Richard Smith confirmed it and added this additional test case:
And likewise:
namespace N {}
namespace N = N;
If a namespace alias really just binds a name to an existing namespace, the
above should be valid, because all declarations of name N in the TU refer to
the same entity.
[Bug c++/67065] Missing diagnostics for ill-formed program with main variable instead of function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67065 --- Comment #2 from Anders Granlund anders.granlund.0 at gmail dot com --- (In reply to Jonathan Wakely from comment #1) (In reply to Anders Granlund from comment #0) The following program is ill-formed (proc.cc): int main; Compile it with the following command line: clang++ prog.cc -std=c++14 -pedantic-errors Erm :-) It fails with G++ too though. Lol. Don't worry, GCC is still my favourite compiler bug generator. :P
[Bug rtl-optimization/67072] Slow code generated for getting each byte of a 64bit register as a LUT index.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67072 --- Comment #4 from Peter Cordes peter at cordes dot ca --- I just timed with Linux perf: time taskset 0x04 perf stat -e task-clock,cycles,instructions,r1b1,r10e,r2c2,r1c2,stalled-cycles-frontend,stalled-cycles-backend ./rs-asmbench my code averages 3.57 fused-domain uops / cycle (3x 1000 iters over a 1MiB buffer). gcc's code averages 3.10 fused-domain uops / cycle (3x 1000 iters over a 1MiB buffer). So it's not just extra mov uops slowing things down. gcc's code isn't scheduled as well. Or else the extra mov uops are taking up execution units and preventing the CPU from running enough load/store uops to go beyond 3 uops per cycle.
[Bug middle-end/62242] ICE in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62242 Louis Krupp t56xjcu6dh at snkmail dot com changed: What|Removed |Added CC||t56xjcu6dh at snkmail dot com --- Comment #3 from Louis Krupp t56xjcu6dh at snkmail dot com --- Created attachment 36095 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36095action=edit Slightly simpler test case
[Bug middle-end/62242] ICE in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62242 --- Comment #5 from Louis Krupp t56xjcu6dh at snkmail dot com --- Created attachment 36097 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36097action=edit Possible patch The problem seems to be with an array constructor with an array element whose value is a character function that is described in an interface block and which has an assumed-length result. I can't claim more than a superficial understanding of the code, but this patch seems to work. I ran make check-fortran, and I saw no regressions.
[Bug middle-end/62242] ICE in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62242 --- Comment #4 from Louis Krupp t56xjcu6dh at snkmail dot com --- Created attachment 36096 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36096action=edit Executable test case
[Bug c++/66842] libatomic uses multiple locks for locked atomics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66842 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added CC||rth at gcc dot gnu.org Severity|normal |enhancement --- Comment #5 from Richard Henderson rth at gcc dot gnu.org --- When libatomic was first written, it wasn't clear what the restrictions from the various languages would be, nor even if that was the best of ideas -- things that would Just Work lock-free would fail on other, less popular platforms. Thus libatomic is written such that accesses to the same object, via different aliased pages, will work. Thus locks are created on a per- cacheline basis covering one page. This does lead to inefficiencies wrt a more straight-forward solution, but very careful thought needs to go into changing it.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #10 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Daniel Gutson from comment #9) Regarding the global register variables, it's a GNU C extension (see https://gcc.gnu.org/onlinedocs/gcc/Explicit-Reg-Vars.html), but I think it should be rejected when compiling in strict mode (e.g. -ansi or -std=c++14). I think this should be filed as a separate issue. Those flags only disable extensions that interfere with well-formed code. To reject extensions, you want the -Werror=pedantic flag.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #11 from Ville Voutilainen ville.voutilainen at gmail dot com --- or simply -pedantic/-pedantic-errors :)
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #12 from Daniel Gutson daniel.gutson at tallertechnologies dot com --- I tried them all, and none of those flags reject a global variable declared as register. I still think a separate issue should be filed.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #13 from Ville Voutilainen ville.voutilainen at gmail dot com --- It is correct that currently none of the pedantic-flags diagnose the use of this extension; perhaps that should be fixed while fixing this bug...
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #14 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Ville Voutilainen from comment #13) It is correct that currently none of the pedantic-flags diagnose the use of this extension; perhaps that should be fixed while fixing this bug... '-Wpedantic' does not cause warning messages for use of the alternate keywords whose names begin and end with '__'. Pedantic warnings are also disabled in the expression that follows '__extension__'. However, only system header files should use these escape routes; application programs should avoid them.
[Bug c++/67064] New: Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
Bug ID: 67064
Summary: Register asm variable broken
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
The following test case fails on x86_64-pc-linux-gnu, powerpc-rtems,
sparc-rtems:
struct s {
int i;
};
register struct s *reg __asm__( 1 );
int f(void)
{
int i;
i = reg-i;
i = (reg)-i;
return i;
}
Yields:
prreg.cc:5:20: warning: call-clobbered register used for global register
variable
register struct s *reg __asm__( 1 );
^
prreg.cc: In function ‘int f()’:
prreg.cc:12:8: error: address of explicit register variable ‘reg’ requested
i = (reg)-i;
^
Please note, that the line 11 i = reg-i; works.
[Bug target/66917] [4.9/5/6 regression] ARM: NEON: memcpy compiles to vst1 with incorrect alignment due to SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Component|tree-optimization |target
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org ---
Actually SRA is fine. vect_compute_data_ref_alignment is, too, leaving
DR_MISALIGNMENT at -1. The target then tells us via
bool is_packed = false;
tree type = (TREE_TYPE (DR_REF (dr)));
if (!known_alignment_for_access_p (dr))
is_packed = not_size_aligned (DR_REF (dr));
if ((TYPE_USER_ALIGN (type) !is_packed)
|| targetm.vectorize.
support_vector_misalignment (mode, type,
DR_MISALIGNMENT (dr), is_packed))
return dr_unaligned_supported;
rm_builtin_support_vector_misalignment (mode=V2DImode, type=0x768280a8,
misalignment=-1, is_packed=true)
at /space/rguenther/tramp3d/trunk/gcc/config/arm/arm.c:27218
27218 if (TARGET_NEON !BYTES_BIG_ENDIAN unaligned_access)
27217 {
27218 if (TARGET_NEON !BYTES_BIG_ENDIAN unaligned_access)
27219 {
27220 HOST_WIDE_INT align = TYPE_ALIGN_UNIT (type);
27221
27222 if (is_packed)
(gdb) p unaligned_access
No symbol unaligned_access in current context.
(gdb) n
27220 HOST_WIDE_INT align = TYPE_ALIGN_UNIT (type);
(gdb)
27222 if (is_packed)
(gdb)
27223 return align == 1;
oops. That's obviously buggy. Not sure what the ARM hook expects in 'type',
but appearantly it's not what the vectorizer passes in here.
Docs say
This hook should return true if the target supports misaligned vector\n\
store/load of a specific factor denoted in the @var{misalignment}\n\
parameter. The vector store/load should be of machine mode @var{mode} and\n\
the elements in the vectors should be of type @var{type}. @var{is_packed}\n\
parameter is true if the memory access is defined in a packed struct.
but the arm hook seems to say yes, I can vectorize with V2DImode
for a vector with element type unsigned long long __attribute__((aligned(1)))
which it obviously cannot.
IMHO the hook should compare required mode alignment with type alignment.
This seems to be the arm hook trying to be too clever.
- target bug.
[Bug target/63679] [5/6 Regression][AArch64] Failure to constant fold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679 --- Comment #36 from rguenther at suse dot de rguenther at suse dot de --- On Wed, 29 Jul 2015, alalaw01 at gcc dot gnu.org wrote: but also feel that those two statements hashing differently is not really helpful! Well, it still uses hash_tree_expr (now 'add_expr') which has to be compatible with operand_equal_p, not just with finding redundancies.
[Bug target/66917] [4.9/5/6 regression] ARM: NEON: memcpy compiles to vst1 with incorrect alignment due to SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
--- Comment #11 from Richard Biener rguenth at gcc dot gnu.org ---
Suggested fix:
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 226348)
+++ gcc/config/arm/arm.c(working copy)
@@ -27217,7 +27217,8 @@ arm_builtin_support_vector_misalignment
{
if (TARGET_NEON !BYTES_BIG_ENDIAN unaligned_access)
{
- HOST_WIDE_INT align = TYPE_ALIGN_UNIT (type);
+ HOST_WIDE_INT align
+ = GET_MODE_ALIGNMENT (TYPE_MODE (type)) / BITS_PER_UNIT;
if (is_packed)
return align == 1;
which produces
push{r4}
add r3, r0, #8
add r4, r1, #8
vld1.64 {d17}, [r1]
vld1.64 {d16}, [r4]
ldr r4, [sp], #4
vld1.64 {d19}, [r3]
veord16, d16, d19
vld1.64 {d18}, [r0]
veord17, d17, d18
vst1.64 {d17}, [r2]!
vst1.64 {d16}, [r2]
bx lr
[Bug c++/65706] [c++14] Pack expansion with variable template incorrectly marked as invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65706
Andreas Herrmann andreash87 at gmx dot ch changed:
What|Removed |Added
CC||andreash87 at gmx dot ch
--- Comment #2 from Andreas Herrmann andreash87 at gmx dot ch ---
I just stumbled up this problem in GCC 5.2.0. And it seems that Bug 66336 is a
duplicate of this one.
$ g++ --version
g++ (GCC) 5.2.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat bug.cc
template class T, T value_
struct constant {
using type = T;
static constexpr T value = value_;
};
template class Constant
constexpr typename Constant::type get = Constant::value;
template class... Args
void callme(Args...) {}
template class... Args
void works(Args...) {
callme(Args::value...);
}
template class... Args
void fails(Args...) {
callme(getArgs...); // !!! Parameter pack is not expanded.
}
int main() {
int x = getconstantint, 1; // The variable template works on its own.
works(constantint, 0{}, constantint, 1{});
fails(constantint, 0{}, constantint, 1{});
}
$ g++ -std=c++14 bug.cc
bug.cc: In function ‘void fails(Args ...)’:
bug.cc:20:21: error: expansion pattern ‘getArgs’ contains no argument packs
callme(getArgs...); // !!! Parameter pack is not expanded.
[Bug target/63304] Aarch64 pc-relative load offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304 --- Comment #22 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to David Abdurachmanov from comment #21) I am on vacations now, but I already marked this on my TODO list. Once I find a free time slot I will give it a spin. I will try to report in a few days. BTW, I will also show up at GNU Tools Cauldron 2015. I must also add that this patch is a pre-requisite for the appropriate iterators to be available. https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02074.html and this may need some rebasing after Alan's latest patches to handle fp16.
[Bug lto/67069] ld: fatal: file .libs/lto-plugin.o: wrong ELF class: ELFCLASS32 during gcc compilation on Solaris 10 x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67069 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Don't use: CFLAGS=-m64 CXXFLAGS=-m64 LDFLAGS=-m64 Instead set CC/CXX to include -m64 instead. Also you might need to default GCC to 64bit too.
[Bug libstdc++/67066] libstdc++-v3/src/filesystem/dir.cc fails to compile with --enable-concept-checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67066 --- Comment #5 from Eric Gallager egall at gwmail dot gwu.edu --- (In reply to Jonathan Wakely from comment #3) Are you playing use as many configure options as possible? Yeah, basically (as many interesting-looking ones as possible, at least). I can confirm that removing the --enable-concept-checks flag works.
[Bug middle-end/67034] [6 Regression] FAIL: gcc.c-torture/compile/pr39928-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67034 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-07-30 Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Alexandre Oliva aoliva at gcc dot gnu.org --- The ICE is fixed with the incremental patch in the git branch aoliva/pr64164. I had to introduce code to copy the incoming byref param to the location assigned by out-of-SSA for the partition holding the default (incoming) SSA version of the parameter. I have only inspected the generated code visually to tell whether the generated code did what I meant it to do, so I'd appreciate some execution testing too. John, if you can help with that, would you like the asm for this one testcase, or is it easy enough for you to give the branch a round of testing? Thanks,
[Bug rtl-optimization/64164] [4.9/5/6 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 --- Comment #48 from Alexandre Oliva aoliva at gcc dot gnu.org --- The errors reported in comments 44, 45, 46, and 47 are fixed in the git branch aoliva/pr64164. I'm giving it all some more testing before posting an updated, consolidated patch.
[Bug fortran/67068] Ambiguous interfaces generated when including open mip fortran header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67068 --- Comment #2 from Mike Glass mwglass at sandia dot gov --- Yes, all the FORTRAN code is compiled with those options. We want to mimic the behavior of the Intel compiler when we add the '-r8' flag to their compiler: Makes default real and complex declarations, constants, functions, and intrinsics 8 bytes long. REAL declarations are treated as DOUBLE PRECISION (REAL(KIND=8)) and COMPLEX declarations are treated as DOUBLE COMPLEX (COMPLEX(KIND=8)). Real and complex constants of unspecified KIND are evaluated in double precision (KIND=8).
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #9 from Daniel Gutson daniel.gutson at tallertechnologies dot com --- Thanks Ville and Jens for looking into this. I'll be able to fix this during next week, so if nobody is available to solve this sooner, then please assign it to me. Regarding the global register variables, it's a GNU C extension (see https://gcc.gnu.org/onlinedocs/gcc/Explicit-Reg-Vars.html), but I think it should be rejected when compiling in strict mode (e.g. -ansi or -std=c++14). I think this should be filed as a separate issue.
[Bug fortran/67068] Ambiguous interfaces generated when including open mip fortran header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67068 --- Comment #3 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Thu, Jul 30, 2015 at 06:24:19PM +, mwglass at sandia dot gov wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67068 --- Comment #2 from Mike Glass mwglass at sandia dot gov --- Yes, all the FORTRAN code is compiled with those options. We want to mimic the behavior of the Intel compiler when we add the '-r8' flag to their compiler: Makes default real and complex declarations, constants, functions, and intrinsics 8 bytes long. REAL declarations are treated as DOUBLE PRECISION (REAL(KIND=8)) and COMPLEX declarations are treated as DOUBLE COMPLEX (COMPLEX(KIND=8)). Real and complex constants of unspecified KIND are evaluated in double precision (KIND=8). You should only need -freal-4-real-8. If your code uses COMMON or EQUIVALENCE, you may also want to use -finteger-4-integer-8 In addition, it is advisable to never mix the -fdefault-* and -freal-* options. These do different things internally, and may in fact cause conflicts.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- C++11 rules about (x) have changed. If you use -std=gnu++98 you would get the same behavior as before.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #2 from Sebastian Huber sebastian.hu...@embedded-brains.de --- Indeed -std=gnu++98 gets rid of this error. So this is working as intended for C++11 and later? This is really nice in combination with defines and macros that use ( ) around its content.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Sebastian Huber from comment #2) Indeed -std=gnu++98 gets rid of this error. So this is working as intended for C++11 and later? This is really nice in combination with defines and macros that use ( ) around its content. From http://en.cppreference.com/w/cpp/language/decltype : Note that if the name of an object is parenthesised, it becomes an lvalue expression, thus decltype(arg) and decltype((arg)) are often different types. Now I don't know the exact rules for lvalue expression so I don't know if it is working the correct way or not.
[Bug middle-end/67053] [6 Regression] FAIL: experimental/optional/constexpr/make_optional.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67053 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Jul 30 07:09:20 2015 New Revision: 226384 URL: https://gcc.gnu.org/viewcvs?rev=226384root=gccview=rev Log: 2015-07-30 Richard Biener rguent...@suse.de PR middle-end/67053 * match.pd: Allow both operands to independently have conversion when simplifying compares of addresses. Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd
[Bug target/67060] [6 Regression] FAIL: gcc.dg/pr56228.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67060 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug middle-end/67053] [6 Regression] FAIL: experimental/optional/constexpr/make_optional.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67053 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/66917] [4.9/5/6 regression] ARM: NEON: memcpy compiles to vst1 with incorrect alignment due to SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.9.4
Summary|[4.9/5/6 regression] ARM: |[4.9/5/6 regression] ARM:
|NEON: memcpy compiles to|NEON: memcpy compiles to
|vld1 and vst1 with |vst1 with incorrect
|incorrect alignment |alignment due to SRA
--- Comment #9 from Richard Biener rguenth at gcc dot gnu.org ---
I see the following, 'a' having an alignment of 8 bytes:
array_ref 0x768201c0
type integer_type 0x767f5d20 uint64_t unsigned DI
size integer_cst 0x768ccf18 constant 64
unit size integer_cst 0x768ccf30 constant 8
align 64 symtab 0 alias set -1 canonical type 0x768d19d8 precision
64 min integer_cst 0x768de210 0 max integer_cst 0x768d7500
18446744073709551615 context translation_unit_decl 0x77ff10f0 D.5218
pointer_to_this pointer_type 0x768215e8
arg 0 component_ref 0x7681f570
type array_type 0x76821540 type integer_type 0x767f5d20
uint64_t
TI
size integer_cst 0x768de228 constant 128
unit size integer_cst 0x768de240 constant 16
align 64 symtab 0 alias set -1 canonical type 0x76821690 domain
integer_type 0x76821498
arg 0 var_decl 0x768d6900 a type union_type 0x768213f0
addressable used BLK file t.c line 12 col 5 size integer_cst
0x768de228 128 unit size integer_cst 0x768de240 16
align 64 context function_decl 0x767f6e00
test_neon_load_store_alignment chain var_decl 0x768d6990 b
arg 1 field_decl 0x769b3558 u type array_type 0x76821540
TI file t.c line 10 col 16 size integer_cst 0x768de228 128
unit size integer_cst 0x768de240 16
align 64 offset_align 64
offset integer_cst 0x768ccee8 constant 0
bit offset integer_cst 0x768ccf48 constant 0 context
union_type 0x768213f0 chain field_decl 0x769b35f0 c
arg 1 integer_cst 0x768de2e8 type integer_type 0x768d1690 int
constant 1
so the smoking dump isn't the reads but the write:
(insn 11 10 0 (set (mem:V2DI (reg/v/f:SI 115 [ outp ]) [0 MEM[(char *
{ref-all})outp_7(D)]+0 S16 A64])
(reg:V2DI 116 [ vect__4.13 ])) t.c:18 -1
(nil))
which for some reason also got 8 byte alignment. I suppose this is
SRA at work as -fno-tree-sra fixes this.
Thus confirmed as SRA problem.
[Bug bootstrap/67066] libstdc++-v3/src/filesystem/dir.cc fails to compile, preventing bootstrapping with libstdcxx-filesystem-ts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67066 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Don't use --enable-concept-checks It enforces C++03 semantics, so doesn't really make much sense these days. Maybe I'll remove the option.
[Bug bootstrap/67066] libstdc++-v3/src/filesystem/dir.cc fails to compile, preventing bootstrapping with libstdcxx-filesystem-ts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67066 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Are you playing use as many configure options as possible? Most of those options are on by default anyway, others don't do anything. I'm pretty sure --enable-libstdcxx-time is redundant on darwin. --enable-multiarch is for Debian Where did you get that command, and if it's causing so much trouble why not try simplifying it?
[Bug lto/67069] New: ld: fatal: file .libs/lto-plugin.o: wrong ELF class: ELFCLASS32 during gcc compilation on Solaris 10 x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67069 Bug ID: 67069 Summary: ld: fatal: file .libs/lto-plugin.o: wrong ELF class: ELFCLASS32 during gcc compilation on Solaris 10 x86-64 Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: zclai at yahoo dot com Target Milestone: --- During gcc 5.2.0 compilation, libtool attempted to make 32bit lto-plugin.o and failed: libtool: link: gcc -shared -Wl,-z -Wl,text -Wl,-h -Wl,liblto_plugin.so.0 -o .libs/liblto_plugin.so.0.0.0 .libs/lto-plugin.o -lc -static-libgcc -m64 ../libiberty/pic/libiberty.a ld: fatal: file .libs/lto-plugin.o: wrong ELF class: ELFCLASS32 ld: fatal: file processing errors. No output written to .libs/liblto_plugin.so.0.0.0 collect2: ld returned 1 exit status gmake[4]: *** [liblto_plugin.la] Error 1 gmake[4]: Leaving directory `/home/alelai/gcc-5.2.0.obj/lto-plugin' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory `/home/alelai/gcc-5.2.0.obj/lto-plugin' gmake[2]: *** [all-stage1-lto-plugin] Error 2 gmake[2]: Leaving directory `/home/alelai/gcc-5.2.0.obj' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/home/alelai/gcc-5.2.0.obj' gmake: *** [all] Error 2 GCC was onfigured as follows: ../gcc-5.2.0.src/configure --prefix=$HOME/gcc-5.2.0 --with-gmp=$HOME/gmp-6.0.0 --with-mpfr=$HOME/mpfr-3.1.3 --with-mpc=$HOME/mpc-1.0.3 --enable-languages=c,c++ CFLAGS=-m64 CXXFLAGS=-m64 LDFLAGS=-m64 --enable-shared gmp, mpfr and mpc had been compiled as 64 bit libs: $ file libgmp.so.10.2.0 libgmp.so.10.2.0: ELF 64-bit LSB shared object, x86-64, version 1, dynamically linked, not stripped $ file libmpfr.so.4.1.3 libmpfr.so.4.1.3: ELF 64-bit LSB shared object, x86-64, version 1, dynamically linked, not stripped $ file libmpc.so.3.0.0 libmpc.so.3.0.0: ELF 64-bit LSB shared object, x86-64, version 1, dynamically linked, not stripped
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #6 from Daniel Gutson daniel.gutson at tallertechnologies dot com --- Please discard my previous comment, I read too fast. I'll do some debugging and get back with some analysis. It seems that cxx_mark_addressable() is wrongly called.
[Bug fortran/67068] Ambiguous interfaces generated when including open mip fortran header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67068 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to Mike Glass from comment #0) Using gfortran-5.2.0 with openmpi 1.8.7 on a Linux RHEL system. When compiling a FORTRAN file with -freal-4-real-8 -fdefault-double-8 -fdefault-real-8 What happens if you don't use the options? You did read the document for the -fdefault-* right? Did you compile everything, and I mean everything, with those options?
[Bug c++/67067] Trouble closing elf file and -static-libstdc++ not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67067 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Alex Lai from comment #1) the error apparently is due to the missing space between -static and -libstdc++. There is no missing space, that's a valid gcc option.
[Bug libstdc++/67066] libstdc++-v3/src/filesystem/dir.cc fails to compile with --enable-concept-checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67066 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-07-30 Component|bootstrap |libstdc++ Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Summary|libstdc++-v3/src/filesystem |libstdc++-v3/src/filesystem |/dir.cc fails to compile, |/dir.cc fails to compile |preventing bootstrapping|with |with|--enable-concept-checks |libstdcxx-filesystem-ts | Ever confirmed|0 |1 Severity|normal |minor --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- The attached errors show that --enable-concept-checks is completely incompatible with the Filesystem library, because it relies on using std::vector in C++14 code and the concept checks enforce C++03 rules. Enabling those checks at build time basically says you want a C++ standard library that only supports C++03, in which case you can't use the C++ Filesystem library which is based on C++14. I can make the build work by disabling the concept checks while building libstdc++fs.a but you still won't be able to use the resulting library unless you also disable them when using it. So you might as well just not configure them to be enabled.
[Bug target/67071] New: GCC misses an optimization to load vector constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67071 Bug ID: 67071 Summary: GCC misses an optimization to load vector constants Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- Host: powerpc64-unknown-linux-gnu Target: powerpc64-unknown-linux-gnu Build: powerpc64-unknown-linux-gnu Gcc has a logic error in rs6000.h which prevents it from being able to load vector constants with the most significant bit set. The code is: #define EASY_VECTOR_MSB(n,mode) \ (((unsigned HOST_WIDE_INT)n) == \ unsigned HOST_WIDE_INT)GET_MODE_MASK (mode)) + 1) 1)) However, if you look at the const_vector that is passed to easy_altivec_constant, the constant is sign extended, and EASY_VECTOR_MSB would not match. If we instead define EASY_VECTOR_MSG to do the mask before doing the comparison the test will succeed, and the code will generate the vector splat integer operation followed by vector shift left. #define EASY_VECTOR_MSB(n,mode) \ unsigned HOST_WIDE_INT)n) GET_MODE_MASK (mode)) == \ unsigned HOST_WIDE_INT)GET_MODE_MASK (mode)) + 1) 1)) A further optimization would be to recognize vector constants where the upper part can be formed via vector splat integer and then the bottom bits are all 0 or all 1, and we can use VSLDOI instruction with a secondary register that is all 0's or all 1's.
[Bug driver/66849] Incorrect multilib chosen with -mthumb -mfloat-abi=hard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66849 --- Comment #3 from simon at pushface dot org --- (In reply to Ramana Radhakrishnan from comment #2) (In reply to simon from comment #0) Having configured with --target=arm-eabi --with-arch=armv7 --with-mode=thumb If you are interested in armv7-m, please use --with-arch=armv7-m firstly. I did this; it made no difference at all. I made an overriding specs file, *multilib: . !marm !mthumb !mfloat-abi=hard; arm marm !mthumb !mfloat-abi=hard; thumb !marm mthumb !mfloat-abi=hard; fpu !marm mthumb mfloat-abi=hard; fpu !marm !mthumb mfloat-abi=hard; arm/fpu marm !mthumb mfloat-abi=hard; which appears to have done the trick. This minimal overriding spec works for me: *multilib: . !mfloat-abi=hard; fpu mfloat-abi=hard; (for reference, don’t use multiple spaces in a specs file!) Next if you want separate multilibs for float-abi=hard you may want to look at some of the commented bits in t-arm to see how to do this or indeed into how --with-multilib-list=aprofile works. GCC has already built separate multilibs! . contains -mfloat-abi=soft thumb likewise - ?? fpu -mfloat-abi-hard It’s just that GCC doesn’t select the right one at link time. I don’t see how this can be resolved invalid”? Alternatively I do think there's something with the M profile libs that can be used today but with some obvious munging to make this work on trunk. https://gcc.gnu.org/ml/gcc-patches/2013-07/msg01072.html Thanks for that. Later, perhaps.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-30 CC||jason at redhat dot com, ||ville.voutilainen at gmail dot com Ever confirmed|0 |1 --- Comment #7 from Ville Voutilainen ville.voutilainen at gmail dot com --- gcc 4.9.2 and 5.2 also reject the snippet if c++14 or c++1z modes are used. gcc 6 accepts the snippet if a c++11 or c++98 mode is explicitly requested, but fails like the others otherwise because it defaults to c++14.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #8 from Jens Maurer jens.maurer at gmx dot net --- In general, x and (x) have the same meaning as per 5.1.1p6. There are a few (spelled-out) exceptions, though. One exception is inside a decltype-specifier, where decltype(e) is different from decltype((e)) as per 7.1.6.2p4. (Another exception is the fact that (f)(y) suppresses argument-dependent lookup for f as per 3.4.2p1. And then, if f is a function-like macro, it doesn't get expanded for (f)(y).) Considering the issue in this ticket, and ignoring the fact that reg should be a block-scope variable, reg is the name of a variable and therefore an lvalue. However, being an lvalue doesn't mean its address is taken. reg-i is equivalent to (reg)-i; in both cases, the lvalue-to-rvalue conversion is applied to reg to determine its pointer value (see 5.3.1p1). In short, using decltype to inspect the type of an expression might be misleading if you don't consider the special case in 7.1.6.2p4. May I venture a guess that the gcc implementation somehow lets the decltype special case bleed into general expression analysis?
[Bug sanitizer/65828] [LTO] ICE in streamer_get_builtin_tree, at tree-streamer-in.c:1127
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65828 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Vittorio Zecca from comment #6) (In reply to Steven Noonan from comment #1) If you want a nice tarball with a ready-to-go repro case, I've put it here: https://www.uplinklabs.net/files/lto-65828.tar.xz Should just be able to run something like: $ /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto1 -quiet -dumpdir .libs/ -dumpbase libglib-2.0.so.0.4400.0.wpa -mtune=generic -march=x86-64 -mtune=generic -march=x86-64 -auxbase libglib_2_0_la-gallocator -O2 -O2 -version -fno-trapv -fPIC -fltrans-output-list=libglib-2.0.so.0.4400.0.ltrans.out -fwpa -fresolution=libglib-2.0.so.res @ccWGeoup.args from inside the extracted directory and see the issue. I just run it with gcc-5.2.0 and I got the following error: ./repro.sh + /home/vitti/local/gcc-5.2.0/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto1 -quiet -dumpdir .libs/ -dumpbase libglib-2.0.so.0.4400.0.wpa -mtune=generic -march=x86-64 -mtune=generic -march=x86-64 -auxbase libglib_2_0_la-gallocator -O2 -O2 -version -fno-trapv -fPIC -fltrans-output-list=libglib-2.0.so.0.4400.0.ltrans.out -fwpa -fresolution=libglib-2.0.so.res @ccWGeoup.args GNU GIMPLE (GCC) version 5.2.0 (x86_64-unknown-linux-gnu) compiled by GNU C version 5.2.0, 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 GIMPLE (GCC) version 5.2.0 (x86_64-unknown-linux-gnu) compiled by GNU C version 5.2.0, 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 lto1: fatal error: bytecode stream generated with LTO version 3.0 instead of the expected 4.0 compilation terminated. That is expected. Using lto files from older compilers is not supported.
[Bug rtl-optimization/67000] [6 Regression] ICE in split_complex_args, at function.c:2325 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67000 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-07-30 Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Alexandre Oliva aoliva at gcc dot gnu.org --- The problem initially reported in this bug is now fixed in the git branch aoliva/pr64164. I'm not sure how to go about duplicating the one in comment 1, but, having fixed a number of additional split_complex issues since the patch that caused the problems was put in, I hope it's fixed too. Gary, would you please detail the toplevel configure and build command lines to trigger it, or perhaps give the branch a try and confirm that it fixes the problem? Thanks,
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Mikhail Maltsev miyuki at gcc dot gnu.org changed: What|Removed |Added CC||miyuki at gcc dot gnu.org --- Comment #26 from Mikhail Maltsev miyuki at gcc dot gnu.org --- Probably, you could use __attribute__((unused)) as a workaround. Some wrapper macro can make it less verbose, e.g. like here: https://github.com/gcc-mirror/gcc/blob/master/include/ansidecl.h#L157 https://github.com/gcc-mirror/gcc/blob/master/gcc/c-family/c-common.c#L6980 You can then add ARG_UNUSED(x)=x (or __attribute__(x)=) to PREDEFINED parameter of your doxygen config (you did not mention the documentation system, but doxygen is used on cryptopp.com). I.e. in your code you'll have: int Foo(int ARG_UNUSED(bar)); the compiler will see it as: int Foo(int bar __attribute__((unused))); and doxygen (and other compilers, if you tweak the macro a bit) as: int Foo(int bar);
[Bug sanitizer/65828] [LTO] ICE in streamer_get_builtin_tree, at tree-streamer-in.c:1127
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65828 Vittorio Zecca zeccav at gmail dot com changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #6 from Vittorio Zecca zeccav at gmail dot com --- (In reply to Steven Noonan from comment #1) If you want a nice tarball with a ready-to-go repro case, I've put it here: https://www.uplinklabs.net/files/lto-65828.tar.xz Should just be able to run something like: $ /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto1 -quiet -dumpdir .libs/ -dumpbase libglib-2.0.so.0.4400.0.wpa -mtune=generic -march=x86-64 -mtune=generic -march=x86-64 -auxbase libglib_2_0_la-gallocator -O2 -O2 -version -fno-trapv -fPIC -fltrans-output-list=libglib-2.0.so.0.4400.0.ltrans.out -fwpa -fresolution=libglib-2.0.so.res @ccWGeoup.args from inside the extracted directory and see the issue. I just run it with gcc-5.2.0 and I got the following error: ./repro.sh + /home/vitti/local/gcc-5.2.0/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto1 -quiet -dumpdir .libs/ -dumpbase libglib-2.0.so.0.4400.0.wpa -mtune=generic -march=x86-64 -mtune=generic -march=x86-64 -auxbase libglib_2_0_la-gallocator -O2 -O2 -version -fno-trapv -fPIC -fltrans-output-list=libglib-2.0.so.0.4400.0.ltrans.out -fwpa -fresolution=libglib-2.0.so.res @ccWGeoup.args GNU GIMPLE (GCC) version 5.2.0 (x86_64-unknown-linux-gnu) compiled by GNU C version 5.2.0, 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 GIMPLE (GCC) version 5.2.0 (x86_64-unknown-linux-gnu) compiled by GNU C version 5.2.0, 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 lto1: fatal error: bytecode stream generated with LTO version 3.0 instead of the expected 4.0 compilation terminated.
[Bug c++/67065] New: Missing diagnostics for ill-formed program with main variable instead of function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67065 Bug ID: 67065 Summary: Missing diagnostics for ill-formed program with main variable instead of function Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: anders.granlund.0 at gmail dot com Target Milestone: --- The following program is ill-formed (proc.cc): int main; Compile it with the following command line: clang++ prog.cc -std=c++14 -pedantic-errors No error messages are given. Since the program is ill-formed I expected to get at least one error message. The program is ill-formed by following sentence in [basic.start.main]p3 (http://eel.is/c++draft/basic.start.main#3): A program that declares a variable main at global scope or that declares the name main with C language linkage (in any namespace) is ill-formed. I have tired this with gcc HEAD 6.0.0 20150729 here: http://melpon.org/wandbox/permlink/uxZxjSFQqBPYXB8b
[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #6 from Pierre-Marie de Rodat derodat at adacore dot com --- Thanks for your answer, Richard! (In reply to Richard Biener from comment #5) So what is the issue with replacing zero-extending an uninitialized %ebp with a random other value? Both are essentially undefined when reached via the somlabel bypass. Well, at least on x86, even when %ebp is uninitialized, “movzwl %bp, %ebp” makes its upper half zero (and yes, the lower half is uninitialized). Hence a following “shr $0x10, %ebp” is supposed to leave zero in %epb, for instance. If we have a random value instead as shr’s input, this does not work anymore, so I consider this transformation is an error. Is the real issue happening in a downstream pass? I don't think REE does anything wrong here. REE is the pass where I observed the change in behavior I described in my first message, and I did not notice anything weird beyond this. If the above is wrong (i.e. if we cannot assume (zext UNDEF from i16 to i32) 16 == 0), then I guess I’ll have to look for something wrong up in the pipe. ;-)
[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Pierre-Marie de Rodat from comment #6) Thanks for your answer, Richard! (In reply to Richard Biener from comment #5) So what is the issue with replacing zero-extending an uninitialized %ebp with a random other value? Both are essentially undefined when reached via the somlabel bypass. Well, at least on x86, even when %ebp is uninitialized, “movzwl %bp, %ebp” makes its upper half zero (and yes, the lower half is uninitialized). Hence a following “shr $0x10, %ebp” is supposed to leave zero in %epb, for instance. If we have a random value instead as shr’s input, this does not work anymore, so I consider this transformation is an error. Is the real issue happening in a downstream pass? I don't think REE does anything wrong here. REE is the pass where I observed the change in behavior I described in my first message, and I did not notice anything weird beyond this. If the above is wrong (i.e. if we cannot assume (zext UNDEF from i16 to i32) 16 == 0), then I guess I’ll have to look for something wrong up in the pipe. ;-) It would be certainly good to see why we have this UNDEF in the first place. But yes, I have to agree that zext UNDEF 16 should be zero. Unlike sext UNDEF which is always undefined as the sign-bit is undefined.
[Bug target/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 Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|6.0 |4.9.4 --- Comment #21 from Uroš Bizjak ubizjak at gmail dot com --- Fixed everywhere.
[Bug rtl-optimization/66891] [6 Regression] ICE in expand_call, at calls.c:3407
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66891 --- Comment #7 from uros at gcc dot gnu.org --- Author: uros Date: Thu Jul 30 08:53:48 2015 New Revision: 226389 URL: https://gcc.gnu.org/viewcvs?rev=226389root=gccview=rev Log: Backport from mainline: 2015-07-17 Uros Bizjak ubiz...@gmail.com PR rtl-optimization/66891 * calls.c (expand_call): Wrap precompute_register_parameters with NO_DEFER_POP/OK_DEFER_POP to prevent deferred pops. 2015-07-15 Uros Bizjak ubiz...@gmail.com PR target/58066 * config/i386/i386.md (*tls_global_dynamic_64_mode): Depend on SP_REG. (*tls_local_dynamic_base_64_mode): Ditto. (*tls_local_dynamic_base_64_largepic): Ditto. (tls_global_dynamic_64_mode): Update expander pattern. (tls_local_dynamic_base_64_mode): Ditto. 2015-07-15 Uros Bizjak ubiz...@gmail.com PR rtl-optimization/58066 * calls.c (expand_call): Precompute register parameters before stack alignment is performed. 2014-05-08 Wei Mi w...@google.com PR target/58066 * config/i386/i386.c (ix86_compute_frame_layout): Update preferred_stack_boundary for call, expanded from tls descriptor. * config/i386/i386.md (*tls_global_dynamic_32_gnu): Update RTX to depend on SP register. (*tls_local_dynamic_base_32_gnu): Ditto. (*tls_local_dynamic_32_once): Ditto. (tls_global_dynamic_64_mode): Set ix86_tls_descriptor_calls_expanded_in_cfun. (tls_local_dynamic_base_64_mode): Ditto. (tls_global_dynamic_32): Set ix86_tls_descriptor_calls_expanded_in_cfun. Update RTX to depend on SP register. (tls_local_dynamic_base_32): Ditto. testsuite/ChangeLog: Backport from mainline: 2015-07-17 Uros Bizjak ubiz...@gmail.com PR target/66891 * gcc.target/i386/pr66891.c: New test. 2014-05-18 Wei Mi w...@google.com PR target/58066 * gcc.target/i386/pr58066.c: Replace pattern matching of .cfi directive with rtl insns. Add effective-target fpic and tls_native. 2014-05-08 Wei Mi w...@google.com PR target/58066 * gcc.target/i386/pr58066.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr58066.c branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr66891.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/i386/i386.c branches/gcc-4_9-branch/gcc/config/i386/i386.md branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[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 #20 from uros at gcc dot gnu.org --- Author: uros Date: Thu Jul 30 08:53:48 2015 New Revision: 226389 URL: https://gcc.gnu.org/viewcvs?rev=226389root=gccview=rev Log: Backport from mainline: 2015-07-17 Uros Bizjak ubiz...@gmail.com PR rtl-optimization/66891 * calls.c (expand_call): Wrap precompute_register_parameters with NO_DEFER_POP/OK_DEFER_POP to prevent deferred pops. 2015-07-15 Uros Bizjak ubiz...@gmail.com PR target/58066 * config/i386/i386.md (*tls_global_dynamic_64_mode): Depend on SP_REG. (*tls_local_dynamic_base_64_mode): Ditto. (*tls_local_dynamic_base_64_largepic): Ditto. (tls_global_dynamic_64_mode): Update expander pattern. (tls_local_dynamic_base_64_mode): Ditto. 2015-07-15 Uros Bizjak ubiz...@gmail.com PR rtl-optimization/58066 * calls.c (expand_call): Precompute register parameters before stack alignment is performed. 2014-05-08 Wei Mi w...@google.com PR target/58066 * config/i386/i386.c (ix86_compute_frame_layout): Update preferred_stack_boundary for call, expanded from tls descriptor. * config/i386/i386.md (*tls_global_dynamic_32_gnu): Update RTX to depend on SP register. (*tls_local_dynamic_base_32_gnu): Ditto. (*tls_local_dynamic_32_once): Ditto. (tls_global_dynamic_64_mode): Set ix86_tls_descriptor_calls_expanded_in_cfun. (tls_local_dynamic_base_64_mode): Ditto. (tls_global_dynamic_32): Set ix86_tls_descriptor_calls_expanded_in_cfun. Update RTX to depend on SP register. (tls_local_dynamic_base_32): Ditto. testsuite/ChangeLog: Backport from mainline: 2015-07-17 Uros Bizjak ubiz...@gmail.com PR target/66891 * gcc.target/i386/pr66891.c: New test. 2014-05-18 Wei Mi w...@google.com PR target/58066 * gcc.target/i386/pr58066.c: Replace pattern matching of .cfi directive with rtl insns. Add effective-target fpic and tls_native. 2014-05-08 Wei Mi w...@google.com PR target/58066 * gcc.target/i386/pr58066.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr58066.c branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr66891.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/i386/i386.c branches/gcc-4_9-branch/gcc/config/i386/i386.md branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002 --- Comment #10 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- (In reply to Oleg Endo from comment #9) Not sure if this is a good idea. I actually think it is the best option as chances are dim otherwise that we find what's actually causing this register indeterminacy. Looking at the build log, it's only gcc/real.o where the comparison fails, all the others (except for the checksum files) are find. I think chances are that, if this is actually a real bug, it might show itself more pronounced when we use gcc-5 to build other packages. Just look at how many bugs we were able to find in gcc-4.9 while using it as the standard host compiler on Debian sh4. You are right that ignoring this failure is most certainly not the best on a release architecture that people rely on. But currently, Debian on sh4 is merely just a port and things are expected to break from time to time. I am currently building now a patched gcc-5_5.2.1-12 which has gcc/real.o added to compare_exclusions, let's see how far we get. Adrian
[Bug fortran/67063] segfault in opening a formatted file at second time with status=replace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67063 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-07-30 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Works for me on COLLECT_GCC=gfc COLLECT_LTO_WRAPPER=/opt/gcc/gcc6w/libexec/gcc/x86_64-apple-darwin14.4.0/6.0.0/lto-wrapper Target: x86_64-apple-darwin14.4.0 Configured with: ../work/configure --prefix=/opt/gcc/gcc6w --enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto --with-gmp=/opt/mp-new --with-system-zlib --with-isl=/opt/mp-new --enable-lto --enable-plugin --with-arch=corei7 --with-cpu=corei7 Thread model: posix gcc version 6.0.0 20150729 (experimental) [trunk revision 226338p2] (GCC) It works also from 4.8 to 5.1. Could you post the output of 'gfortran -v'?
[Bug middle-end/67052] tree_single_nonnegative_warnv_p and fold_relational_const are inconsistent with NaNs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67052
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
This means that the ABS_EXPRx 0 code is correct in simplifying
NaN 0 to true and it is correct to _not_ simplify NaN = 0 to true.
But at the same time it has to do the same as fold_relational_const and
preserve traps with -ftrapping-math for the ordered compares.
So the following patch should fix the inconsistency and avoid the wrong-code
issue in the ABS_EXPRx 0 folding:
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 226387)
+++ gcc/fold-const.c(working copy)
@@ -11634,7 +11455,9 @@ fold_binary_loc (location_t loc,
/* Convert ABS_EXPRx 0 to false. */
strict_overflow_p = false;
if (code == LT_EXPR
- (integer_zerop (arg1) || real_zerop (arg1))
+ (integer_zerop (arg1)
+ || ((! HONOR_NANS (arg0) || !flag_trapping_math)
+ real_zerop (arg1)))
tree_expr_nonnegative_warnv_p (arg0, strict_overflow_p))
{
if (strict_overflow_p)
