[Bug rtl-optimization/63620] RELOAD lost SET_GOT dependency on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620 Igor Zamyatin changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #5 from Igor Zamyatin --- (In reply to Uroš Bizjak from comment #3) > Confirmed. This will affect all SSE targets. Have you managed to reproduce the issue on i686? > The patch at Comment #2 will just paper over the issue. Yeah, it was just a temporary fix for Darwin folks
[Bug rtl-optimization/63620] RELOAD lost SET_GOT dependency on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620 --- Comment #6 from Uroš Bizjak --- (In reply to Igor Zamyatin from comment #5) > > Confirmed. This will affect all SSE targets. > > Have you managed to reproduce the issue on i686? No, only with a crosscompiler to x86_64-apple-darwin11. The i686-linux looks OK.
[Bug rtl-optimization/63620] RELOAD lost SET_GOT dependency on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620 --- Comment #7 from Uroš Bizjak --- The difference si that the call to f128_p3 does not expand with "use (reg:SI bx)" tag in the Darwin case. Probably ix86_expand_call should be fixed for TARGET_MACHO. However, even if this will solve bootstrap, the RA should be fixed to mark PIC register live in case when constant is moved to memory.
[Bug target/63652] New: [AArch64_be] vzip/vuzp tests fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63652 Bug ID: 63652 Summary: [AArch64_be] vzip/vuzp tests fail Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org The vzip/vuzp tests from gcc.target/aarch64/advsimd-intrinsics fail at execution when the target is aarch64_be. I am using aarch64_be-none-elf with the Foundation Model as execution engine, so it could be a bug in that simulator.
[Bug tree-optimization/63641] [5 Regression] Invalid shift leads to incorrect code on 32-bit system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63641 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug target/63653] New: [AArch64_be] vldX/vldX_lane tests fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63653 Bug ID: 63653 Summary: [AArch64_be] vldX/vldX_lane tests fail Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org The vldX and vldX_lane tests in gcc.target/aarch64/advsimd-intrinsics fail at execution when target is AArch64_be. I'm using aarch64_be-none-elf with the Foundation Model to run the tests, it could be a bug in the simulator.
[Bug c/63645] Incorrect code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jsm28 at gcc dot gnu.org --- Comment #13 from Jakub Jelinek --- Pedantically speaking, the testcase is invalid I think, in C writing one union member invalidates all the other union members. But as a GNU extension, we allow more relaxed handling of unions, type punning through unions etc., and regarding the sizes of the objects, I believe we do allow having size of just one of the union members for the whole object, what else are union tree_node in tree-core.h or struct rtx_def's union u in rtl.h in GCC sources? So, just by quickly saying what the testcase does is invalid even under extensions I believe most of the GCC codebase would be similarly invalid, don't we use heavily if (TREE_CODE (t) == VAR_DECL && DECL_HARD_REGISTER (t)) and similar? TREE_CODE being t->base.code and DECL_HARD_REGISTER t->decl_with_vis.hard_register ? Here for many trees, the allocated size of them is smaller than offsetof of the decl_with_vis.hard_register field, the reason why we never hit this problem is just that sizeof (tree_base) is 8, and thus the fold_truth_andor_1 optimization doesn't consider if (a->fld1 == N && a->fld2 == M) to be adjacent tnough to optimize. I believe this is the fold_truth_andor_1 optimization at work, the question is how we'd want to change that optimization. I'd say giving up immediately if you access different union members would be too pessimistic, so perhaps just bail out if the size of the first union member is smaller than the offset of the second access + access size?
[Bug c++/63654] New: An explicit copy constructor should be used in the second step of a class copy-initialization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63654
Bug ID: 63654
Summary: An explicit copy constructor should be used in the
second step of a class copy-initialization.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kariya_mitsuru at hotmail dot com
Created attachment 33815
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33815&action=edit
gcc -v
The sample code below should be compiled successfully but it causes a
compilation error by gcc.
sample code ===
struct S {
explicit S(const S&) {}
S(int) {}
};
int main()
{
S s = 1;
}
= compiler output
prog.cc: In function 'int main()':
prog.cc:8:11: error: no matching function for call to 'S::S(S)'
S s = 1;
^
prog.cc:3:5: note: candidate: S::S(int)
S(int) {}
^
prog.cc:3:5: note: no known conversion for argument 1 from 'S' to 'int'
prog.cc:3:5: note: after user-defined conversion: S::S(int)
= compiler output
cf. http://melpon.org/wandbox/permlink/fA27PoaI9y9q2Xz6
C++ standard [dcl.init]/p.17.6.2 says that
... The result of the call (which is the temporary for the constructor case) is
then used to direct-initialize, according to the rules above, the object that
is the destination of the copy-initialization. ...
I think that the variable "s" should be *direct-initialize* from the result of
the call "S(int)", so the explicit copy constructor "explicit S(const S&)"
should be used.
(at least if the option "-pedantic-errors" is specified)
[Bug fortran/63205] [OOP] Wrongly rejects type = class (for identical declared type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63205 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- I am well on my way to a fix for all these issues of class assignment to type. I'll try to post where I have got up to in the next 24 hours. Getting the scalarizer to swallow the class array valued functions has been quite a trip down memory lane :-) Paul
[Bug c++/54521] g++ fails to call explicit constructors in the second step of copy initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54521 Jonathan Wakely changed: What|Removed |Added CC||kariya_mitsuru at hotmail dot com --- Comment #5 from Jonathan Wakely --- *** Bug 63654 has been marked as a duplicate of this bug. ***
[Bug c++/63654] An explicit copy constructor should be used in the second step of a class copy-initialization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63654 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- duplicate *** This bug has been marked as a duplicate of bug 54521 ***
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #48 from Dominique d'Humieres --- > --- Comment #44 from Iain Sandoe --- > (In reply to Stupachenko Evgeny from comment #43) [...] > there were at one point this week 4 concurrent bootstrap breaks on dariwn. > > this PR. > the ipa-icf series > requiring non-weak aliases <-- this is pr63622 > and the iconv dep on libcpp.<-- AFAICT this should be fixed now In addition r216154 breaks a lot of asan tests with -m32: see https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg02834.html
[Bug rtl-optimization/63620] RELOAD lost SET_GOT dependency on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620 --- Comment #8 from Stupachenko Evgeny --- (In reply to Uroš Bizjak from comment #7) > The difference si that the call to f128_p3 does not expand with "use (reg:SI > bx)" tag in the Darwin case. Probably ix86_expand_call should be fixed for > TARGET_MACHO Darwin generates indirect access throw generated section: .symbol_stub. They don't use EBX in the call even without any changes (relaxing EBX usage). > > However, even if this will solve bootstrap, the RA should be fixed to mark > PIC register live in case when constant is moved to memory.
[Bug rtl-optimization/63620] RELOAD lost SET_GOT dependency on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620 --- Comment #9 from Uroš Bizjak --- (In reply to Stupachenko Evgeny from comment #8) > (In reply to Uroš Bizjak from comment #7) > > The difference si that the call to f128_p3 does not expand with "use (reg:SI > > bx)" tag in the Darwin case. Probably ix86_expand_call should be fixed for > > TARGET_MACHO > > Darwin generates indirect access throw generated section: .symbol_stub. > They don't use EBX in the call even without any changes (relaxing EBX usage). I guess that the mentioned "use" in the call is what keeps PIC register live accross push in the non-Darwin case.
[Bug c++/63650] conflicting type attributes specified for ‘virtual..'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63650 --- Comment #7 from Richard PALO --- Further testing indicates that 'cdecl' is okay and that keeping 'regparm(0)' causes the error.
[Bug tree-optimization/63655] New: ice using -O2 -floop-parallelize-all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63655 Bug ID: 63655 Summary: ice using -O2 -floop-parallelize-all Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hete2 at gmx dot de Created attachment 33816 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33816&action=edit preprocessed source I'm using Ubuntu 14.04 on an AMD64 (Sandy-bridge) Computer. gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) Compiling gegl0.2.0 results in an ice: gegl-processor.c:539:1: internal compiler error: Segmentation fault region_area (GeglRegion *region) ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Preprocessed source stored into /tmp/cc1j8zH0.out file, please attach this to your bugreport. when configured with: ./configure CFLAGS='-O2 -floop-parallelize-all'. -O2 or -floop-parallelize-all alone gives no error. This ICE happens with gcc 4.8.3 and gcc 4.9.1 also.
[Bug sanitizer/63646] libsanitizer fails to build for AARCH64:ILP32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63646 Yury Gribov changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #4 from Yury Gribov --- (In reply to Andrew Pinski from comment #2) > Really I think sanitizer should be auto-generating this header rather than > having its own copy. People keep mentioning this but Asan team never seemed to bother. Actually missing symbols is not the biggest problems because they at least manifest themselves at build time. Have a look at bunch of lovely magic constants with interspersing ifdefs all over the place in sanitizer_platform_limits_posix.h. Debugging type mismatch issues at runtime is so fun.
[Bug ada/63656] New: a-tags.adb:82:04: warning: types for unchecked conversion have different sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63656 Bug ID: 63656 Summary: a-tags.adb:82:04: warning: types for unchecked conversion have different sizes Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: arekm at maven dot pl I'm trying to build gcc from current 4.9 branch (so, future 4.9.2). Unfortunately: /home/users/arekm/rpm/BUILD/gcc-4.9.1/builddir/./gcc/xgcc -B/home/users/arekm/rpm/BUILD/gcc-4.9.1/builddir/./gcc/ -B/usr/x86_64-pld-linux/bin/ -B/usr/x86_64-pld-linux/lib/ -isystem /usr/x86_64-pld-linux/include -isystem /usr/x86_64-pld-linux/sys-include-c -O2 -m32 -fPIC -W -Wall -gnatpg -nostdinc -m32 \ a-tags.adb -o a-tags.o a-tags.adb:82:04: warning: types for unchecked conversion have different sizes a-tags.adb:85:04: warning: types for unchecked conversion have different sizes a-tags.adb:90:04: warning: types for unchecked conversion have different sizes a-tags.adb:93:04: warning: types for unchecked conversion have different sizes a-tags.adb:96:04: warning: types for unchecked conversion have different sizes a-tags.adb:102:04: warning: types for unchecked conversion have different sizes a-tags.adb:105:04: warning: types for unchecked conversion have different sizes a-tags.adb:108:04: warning: types for unchecked conversion have different sizes a-tags.adb:111:04: warning: types for unchecked conversion have different sizes a-tags.adb:766:07: warning: types for unchecked conversion have different sizes ../gcc-interface/Makefile:3112: polecenia dla obiektu 'a-tags.o' nie powiodły się make[10]: *** [a-tags.o] Błąd 1 make[10]: Opuszczenie katalogu '/home/users/arekm/rpm/BUILD/gcc-4.9.1/builddir/gcc/ada/rts_32' configured as: $ ../configure --prefix=/usr --with-local-prefix=/usr/local --libdir=/usr/lib64 --libexecdir=/usr/lib64 --infodir=/usr/share/info --mandir=/usr/share/man --x-libraries=/usr/lib64 --enable-bootstrap --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-c99 --enable-checking=release --disable-cld --enable-cmath --enable-decimal-float --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++,fortran,objc,obj-c++,ada,java,go --enable-libgomp --enable-libitm --enable-libmudflap --enable-linker-build-id --enable-linux-futex --enable-long-long --enable-nls --enable-lto --enable-plugin --enable-shared --enable-threads=posix --disable-werror --with-cloog --with-demangler-in-ld --with-gnu-as --with-gnu-ld --with-linker-hash-style=gnu --with-long-double-128 --with-ppl --disable-ppl-version-check --with-slibdir=/lib64 --without-system-libunwind --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-libstdcxx-threads --enable-libstdcxx-time=rt --enable-libstdcxx-visibility --enable-symvers=gnu --with-gxx-include-dir=/usr/include/c++/4.9.1 --disable-gconf-peer --enable-gtk-cairo --enable-java-awt=xlib,gtk --enable-jni --enable-libgcj --enable-libgcj-multifile --enable-libgcj-database --disable-libjava-multilib --enable-static-libjava --enable-xmlj --with-pkgversion=PLD-Linux --with-bugurl=http://bugs.pld-linux.org x86_64-pld-linux system: Linux, glibc 2.20, x86_64 Found similar bug #56030. It wasn't fixed because "X32 isn't usable for Ada." but regular x86 32bit are usable (I assume).
[Bug sanitizer/63638] [4.9 Regression] internal compiler error: in asan_expand_check_ifn (with -fsanitize=address)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63638 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.3 --- Comment #6 from Richard Biener --- Fixed.
[Bug c/63645] Incorrect code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645 --- Comment #14 from M Welinder --- > 1) Your malloc is too small. It has to be sizeof (biggest member). > So you're invoking undefined behavior. Can you produce a specific authoritative reference for that statement? I.e., a reference to the standard not "because I say so". Note, that the standard's Section 6.5 #7 says that I *can* accees my GnmExprBinary object through the union. > 2) In the if statement, where you probe the different members, you > also invoke undefined behavior. Absolutely not! I went other that in painful detail in comment 8. Bottom line: only one member is accessed. > Pedantically speaking, the testcase is invalid I think, in C writing > one union member invalidates all the other union members. While true as written, there is a read-side exception to that which allows reading the active union member's fields through certain inactive union members' fields: [#5] With one exception, if the value of a member of a union object is used when the most recent store to the object was toadifferent member, the behavior is implementation-defined.70) One special guarantee is made in order to simplify the use of unions: If a union contains several structures that share a common initial sequence (see below), and if the union object currently contains one of these structures, it is permitted to inspect the common initial part of any of them anywhere that a declaration of the completed type of the union is visible. Two structures share a common initial sequence if corresponding members have compatible types (and, for bit-fields, the same widths) for a sequence of one or more initial members.
[Bug rtl-optimization/63620] RELOAD lost SET_GOT dependency on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620 --- Comment #10 from Stupachenko Evgeny --- (In reply to Uroš Bizjak from comment #9) > (In reply to Stupachenko Evgeny from comment #8) > > (In reply to Uroš Bizjak from comment #7) > > > The difference si that the call to f128_p3 does not expand with "use > > > (reg:SI > > > bx)" tag in the Darwin case. Probably ix86_expand_call should be fixed for > > > TARGET_MACHO > > > > Darwin generates indirect access throw generated section: .symbol_stub. > > They don't use EBX in the call even without any changes (relaxing EBX > > usage). > > I guess that the mentioned "use" in the call is what keeps PIC register live > accross push in the non-Darwin case. Not sure I understand Darwin features correct, but they push shifted esp to calls: (objdump of example for PR63618) 0d20 <_f128_square>: d20: 56 push %esi d21: 83 ec 18sub$0x18,%esp d24: 66 0f 6f 44 24 30 movdqa 0x30(%esp),%xmm0 d2a: 89 e0 mov%esp,%eax d2c: 83 ec 2csub$0x2c,%esp d2f: 8b 74 24 4c mov0x4c(%esp),%esi d33: 0f 11 44 24 1c movups %xmm0,0x1c(%esp) d38: 0f 11 44 24 0c movups %xmm0,0xc(%esp) d3d: 50 push %eax d3e: e8 f9 00 00 00 call e3c <___multf3$stub> d43: 89 f0 mov%esi,%eax d45: 66 0f 6f 4c 24 2c movdqa 0x2c(%esp),%xmm1 d4b: 0f 29 0emovaps %xmm1,(%esi) d4e: 83 c4 44add$0x44,%esp d51: 5e pop%esi d52: c2 04 00ret$0x4 Anyway, if call is not EBX dependent (say local call in Linux) the issue is not reproduced (like in example from PR63618). So the issue looks like Darwin dependent RA issue.
[Bug c/63645] Incorrect code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645 --- Comment #15 from M Welinder --- FYI, I filed a related bug for valgrind covering the problem with the conditional jump being detected as undefined: https://bugs.kde.org/show_bug.cgi?id=340392
[Bug target/63610] OSX 10.10 (Yosemite) segfault in MPIR testsuite with -O0 or -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610 howarth at bromo dot med.uc.edu changed: What|Removed |Added CC||howarth at bromo dot med.uc.edu --- Comment #6 from howarth at bromo dot med.uc.edu --- Created attachment 33817 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33817&action=edit convenience patch
[Bug target/63610] OSX 10.10 (Yosemite) segfault in MPIR testsuite with -O0 or -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610
--- Comment #7 from howarth at bromo dot med.uc.edu ---
I can confirm that there are many regressions (particularly in the fortran test
suite) on Yosemite due to the libtool bug which causes shared libraries to be
linked as if the target was Puma. The attached convenience patch solves the
issue (which should only be triggered if MACOSX_DEPLOYMENT_TARGET is being
set). The fix is of the form...
Index: gcc-4.9.1/gcc/configure
===
--- gcc-4.9.1.orig/gcc/configure
+++ gcc-4.9.1/gcc/configure
@@ -14415,7 +14415,7 @@ $as_echo "$lt_cv_ld_force_load" >&6; }
case ${MACOSX_DEPLOYMENT_TARGET-10.0},$host in
10.0,*86*-darwin8*|10.0,*-darwin[91]*)
_lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
- 10.[012]*)
+ 10.[012][,.]*)
_lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined
${wl}suppress' ;;
10.*)
_lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
[Bug target/63610] OSX 10.10 (Yosemite) segfault in MPIR testsuite with -O0 or -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610 --- Comment #8 from Volker Braun --- Another workaround is to set MACOSX_DEPLOYMENT_TARGET=10.9 Libtool-2.4.3 will have the fix, gcc (and everybody else) should just reconfigure when its out. http://lists.gnu.org/archive/html/libtool/2014-10/msg1.html
[Bug rtl-optimization/63620] RELOAD lost SET_GOT dependency on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620 --- Comment #11 from Uroš Bizjak --- (In reply to Stupachenko Evgeny from comment #10) > Anyway, if call is not EBX dependent (say local call in Linux) the issue is > not reproduced (like in example from PR63618). > So the issue looks like Darwin dependent RA issue. True. In Darwin case, RA allocates %eax, which is call-used register and clobbered by the call to f128_p3. I don't see %eax saved around the call. In Linux case, RA allocates %edi, which is call-saved.
[Bug fortran/58644] [OOP] Missing .data ref in passing a CLASS array as actual argument to a TYPE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58644 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #1) > I don't understand this PR. The test succeeds even when compiled with > -fsanitize=address. I think that the PR is justified. The actual argument should be as Tobias says. Both &D.2108 and &D.2108.data are valid address. Not only this, they are the same address. However, should we ever change the class ABI to put the vptr first, for example, then this will no longer work. I believe that my imminent fix for PR63205 will correct this issue and so eliminate this PR. Paul
[Bug c++/63657] New: [4.9 regression] -Wunused-variable: warning supressed by virtual dtor fn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63657
Bug ID: 63657
Summary: [4.9 regression] -Wunused-variable: warning supressed
by virtual dtor fn
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: petschy at gmail dot com
The under code has two unused variables, which are references to classes. We
should have two warnings, however 4.9.1 and 5.0 trunk gives just one. 4.7.2 and
4.8.3 are ok. The second warning is supressed by the virtual dtor in Bar. Only
the dtor does the trick, if I comment it out or instead I define a plain
virtual fn, the warning appears.
g++-4.8 -Wunused-variable -c 20141022-unused_warn.cpp
20141022-unused_warn.cpp: In function ‘void foo()’:
20141022-unused_warn.cpp:7:7: warning: unused variable ‘f’ [-Wunused-variable]
Foo& f = getfoo();
^
20141022-unused_warn.cpp: In function ‘void bar()’:
20141022-unused_warn.cpp:18:7: warning: unused variable ‘b’ [-Wunused-variable]
Bar& b = getbar();
^
g++-5.0.0 -Wunused-variable -c 20141022-unused_warn.cpp
20141022-unused_warn.cpp: In function ‘void foo()’:
20141022-unused_warn.cpp:7:7: warning: unused variable ‘f’ [-Wunused-variable]
Foo& f = getfoo();
^
8<8<8<
class Foo
{
};
Foo& getfoo();
void foo()
{
Foo& f = getfoo();
}
class Bar
{
virtual ~Bar() {}
};
Bar& getbar();
void bar()
{
Bar& b = getbar();
}
[Bug target/63610] OSX 10.10 (Yosemite) segfault in MPIR testsuite with -O0 or -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610 --- Comment #9 from howarth at bromo dot med.uc.edu --- Alternatively, you can just make sure you don't set MACOSX_DEPLOYMENT_TARGET in your shell. Also mote that gmp, mpfr and mpc also suffer from this bug and, if built on 10.10, should either have their configure scripts patched or regenerated with the fixed libtool.
[Bug other/62279] Demangler crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62279 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-27 CC||ktietz at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Kai Tietz --- confirmed. Can be easily reporduced by using cxxfilt tool.
[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114
--- Comment #9 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Mon Oct 27 14:04:43 2014
New Revision: 216736
URL: https://gcc.gnu.org/viewcvs?rev=216736&root=gcc&view=rev
Log:
[Vectorizer] Make REDUC_xxx_EXPR tree codes produce a scalar result
PR tree-optimization/61114
* expr.c (expand_expr_real_2): For REDUC_{MIN,MAX,PLUS}_EXPR, add
extract_bit_field around optab result.
* fold-const.c (fold_unary_loc): For REDUC_{MIN,MAX,PLUS}_EXPR, produce
scalar not vector.
* tree-cfg.c (verify_gimple_assign_unary): Check result vs operand type
for REDUC_{MIN,MAX,PLUS}_EXPR.
* tree-vect-loop.c (vect_analyze_loop): Update comment.
(vect_create_epilog_for_reduction): For direct vector reduction, use
result of tree code directly without extract_bit_field.
* tree.def (REDUC_MAX_EXPR, REDUC_MIN_EXPR, REDUC_PLUS_EXPR): Update
comment.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/fold-const.c
trunk/gcc/tree-cfg.c
trunk/gcc/tree-vect-loop.c
trunk/gcc/tree.def
[Bug tree-optimization/61114] Scalar evolution hides a big-endian const-folding bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114 --- Comment #10 from alalaw01 at gcc dot gnu.org --- Author: alalaw01 Date: Mon Oct 27 14:20:52 2014 New Revision: 216737 URL: https://gcc.gnu.org/viewcvs?rev=216737&root=gcc&view=rev Log: Add new optabs for reducing vectors to scalars PR tree-optimization/61114 * doc/md.texi (Standard Names): Add reduc_(plus,[us](min|max))|scal optabs, and note in reduc_[us](plus|min|max) to prefer the former. * expr.c (expand_expr_real_2): Use reduc_..._scal if available, fall back to old reduc_... + BIT_FIELD_REF only if not. * optabs.c (optab_for_tree_code): for REDUC_(MAX,MIN,PLUS)_EXPR, return the reduce-to-scalar (reduc_..._scal) optab. (scalar_reduc_to_vector): New. * optabs.def (reduc_smax_scal_optab, reduc_smin_scal_optab, reduc_plus_scal_optab, reduc_umax_scal_optab, reduc_umin_scal_optab): New. * optabs.h (scalar_reduc_to_vector): Declare. * tree-vect-loop.c (vectorizable_reduction): Look for optabs reducing to either scalar or vector. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/md.texi trunk/gcc/expr.c trunk/gcc/optabs.c trunk/gcc/optabs.def trunk/gcc/optabs.h trunk/gcc/tree-vect-loop.c
[Bug c/63645] Incorrect code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #16 from Markus Trippelsdorf ---
(In reply to M Welinder from comment #14)
> > 2) In the if statement, where you probe the different members, you
> > also invoke undefined behavior.
>
> Absolutely not! I went other that in painful detail in comment 8.
> Bottom line: only one member is accessed.
Let's take this example:
markus@x4 tmp % cat union.c
#include
typedef union _GnmExpr GnmExpr;
typedef char GnmFunc;
typedef unsigned char guint8;
typedef enum
{
GNM_EXPR_OP_LT,
GNM_EXPR_OP_FUNCALL
} GnmExprOp;
typedef struct
{
guint8 oper;
int argc;
GnmFunc *func;
} GnmExprFunction;
typedef struct
{
guint8 oper;
} GnmExprBinary;
union _GnmExpr
{
GnmExprFunction func;
GnmExprBinary binary;
};
int
main (void)
{
GnmExprBinary res;
res.oper = GNM_EXPR_OP_LT;
GnmExpr const *expr = (GnmExpr *)&res;
if (expr->binary.oper == GNM_EXPR_OP_FUNCALL
&& expr->func.argc == 1
&& expr->func.func == getenv ("NOT"))
abort ();
return 0;
}
Here the compiler even warns:
markus@x4 tmp % gcc -Wall -Wextra -g -O2 union.c
union.c: In function ‘main’:
union.c:40:7: warning: ‘res.func.func’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
&& expr->func.func == getenv ("NOT"))
^
And that is because the compiler assumes that no undefined behavior
happens and optimizes accordingly.
The gcc documentation even mentions this case explicitly (under
-fstrict-aliasing):
»Similarly, access by taking the address, casting the resulting pointer and
dereferencing the result has undefined behavior, even if the cast uses a union
type.«
[Bug c++/23055] overload resolution does not find templated function (zero -> pointer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23055 Jonathan Wakely changed: What|Removed |Added CC||shunichi_wakabayashi@yahoo. ||co.jp --- Comment #13 from Jonathan Wakely --- *** Bug 63648 has been marked as a duplicate of this bug. ***
[Bug c++/63648] compile error w/ pointer argument of result_of-is_same-enable_if returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63648 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- I think this is a duplicate of PR 23055 which was fixed for 4.9.0 *** This bug has been marked as a duplicate of bug 23055 ***
[Bug c++/63658] New: [4.8/4.9 Regression] Using class reference as template parameter causes compilation to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63658 Bug ID: 63658 Summary: [4.8/4.9 Regression] Using class reference as template parameter causes compilation to fail Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: patrick.riphagen at xsens dot com Created attachment 33818 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33818&action=edit Source code containing the bug We have a template class which is based on a descriptor class. The template class is specialized later on. I have attached a stripped version of the problematic code. Using gcc 4.7 and 4.8 we did not have a problem compiling this code. Using gcc 4.9.1 (gcc version 4.9.1 (Ubuntu 4.9.1-16ubuntu6) ) this code does not compile anymore. The error is: main.cpp:15:17: error: prototype for ‘void foo::size() [with Descriptor& D = (* & g_descriptor)]’ does not match any in class ‘foo<(* & g_descriptor)>’ template<> void foo::size() ^ main.cpp:11:7: error: candidate is: void foo::size() [with Descriptor& D = (* & g_descriptor)] void size (); It looks like the prototype for and candidate look exactly the same, however compilation still fails
[Bug target/61915] [AArch64] High amounts of GP to FP register moves using LRA on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915 --- Comment #18 from Wilco --- (In reply to Andrew Pinski from comment #17) > (In reply to Wilco from comment #16) > > (In reply to Andrew Pinski from comment #13) > > > (In reply to Wilco from comment #9) > > > > I committed a workaround > > > > (http://gcc.gnu.org/ml/gcc-patches/2014-09/msg00362.html) by increasing > > > > the > > > > int<->fp move cost. Can you try this and check the issue has indeed > > > > gone? > > > > You need -mcpu=cortex-a57. > > > > > > Note when I submitted ThunderX support I used a base of 2 instead of a > > > base > > > of 1 due to 2 being the default and all values are relative to that. This > > > is mentioned in https://gcc.gnu.org/onlinedocs/gccint/Costs.html . In > > > fact > > > a value of 2 means reload will not look at the constraints of a move > > > instruction. > > > > > > So I think the cortex* cpus should also re-base these values based on 2 > > > being gpr-to-gpr value. > > > > You mean only use multiples of 2? That's interesting as I've not seen that > > done elsewhere. Are these costs in any way related to real issue and latency > > cycles? Most targets have complex tables with all the exact latencies for > > every little uarch detail, but from what I've seen in the allocator these > > costs have almost no meaning. > > Not always multiple of 2 though in the case of ThunderX they are multiple of > twos. The costs are not really directly related to the latency cost but it > is relative to one another. So I could have used 2, 3, 4 (meaning latency > of 1, 2, 3) instead. I used the factor of 2 instead of 1 for ThunderX > because 2 + 3 != 4 but rather 5. OK. > > So did you find that setting the FP move cost so low actually works alright > > on ThunderX? I'd like to figure out a setting for the generic target that > > works out well across all AArch64 implementations. > > Yes it seems to at least on the things we have benchmarked but we have not > done much big benchmarks like SPEC yet. Well in one testcase I'm seeing 11 str and 26 ldr spills on a53/a57 but 407 fmoves on thunderx. I don't see how that could be a good tradeoff unless fmov has negative latency...
[Bug target/59799] aarch64_pass_by_reference never passes arrays by value, contrary to ABI documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59799 Ramana Radhakrishnan changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #10 from Ramana Radhakrishnan --- This is fixed for 5.0 - we aren't taking ABI changes back into release branches AFAIK.
[Bug c++/63658] [4.8/4.9 Regression] Using class reference as template parameter causes compilation to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63658 Jonathan Wakely changed: What|Removed |Added Severity|major |normal
[Bug c/63645] Incorrect code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645 --- Comment #17 from M Welinder --- You keep saying "undefined behaviour", but you keep avoiding substantiating that claim. Where, in the C99 standard, is the clause that makes things undefined?
[Bug c++/63658] [4.9/5 Regression] Using class reference as template parameter causes compilation to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63658 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-27 Summary|[4.8/4.9 Regression] Using |[4.9/5 Regression] Using |class reference as template |class reference as template |parameter causes|parameter causes |compilation to fail |compilation to fail Ever confirmed|0 |1
[Bug c/63645] Incorrect code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645 --- Comment #18 from M Welinder --- The example at strict-aliasing in the gcc man page covers a different situation: you don't get to access a double via an int. I get it. But the standard says that in certain circumstances you really do get to access one structure via the fields of another. I quoted that part for you. So if undefined behaviour is going on, it's something else. It is possible, I guess, but hand waving doesn't establish it.
[Bug c/63645] Incorrect code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645 --- Comment #19 from joseph at codesourcery dot com --- Given GnmExprBinary res; GnmExpr const *expr = (GnmExpr *)&res; the C standard does not define where the result of the conversion points; all that's defined is that if converted directly back to GnmExprBinary * (not via some sequence of intermediate types) it compares equal to the original pointer, if the original pointer was sufficiently aligned for GnmExpr * (and it is likely the latter type has stricter alignment requirements than GnmExprBinary *). The effect is that the pointer resulting from the conversion cannot be dereferenced, only compared and converted back. It is these limits on what pointer conversions are defined, together with the direct rules on what types of lvalues may access an object, that restrict aliasing in C.
[Bug ipa/63576] [5 Regression] ICE : in ipa_merge_profiles, at ipa-utils.c:540 during Firefox LTO/PGO build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63576 Ilya Palachev changed: What|Removed |Added CC||i.palachev at samsung dot com --- Comment #3 from Ilya Palachev --- (In reply to Jan Hubicka from comment #2) > speculative edges come in pairs (direct, indirect edge) that is obtained by > speculative_call_info. THen you need to sum counts (instead of taking ones > from BB) and turn them back to frequencies (because it is profile only > counts should be non-0) Suggested patch https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02764.html Jan, so you mean that counts from BBs and counts from speculative edges should be sumed?
[Bug c/63645] Incorrect code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645 --- Comment #20 from Jakub Jelinek --- (In reply to jos...@codesourcery.com from comment #19) > Given > > GnmExprBinary res; > GnmExpr const *expr = (GnmExpr *)&res; Let's consider if in #c11 you change: GnmExprBinary *res = malloc (sizeof (GnmExprBinary)); res->oper = op; return (GnmExpr*)res; to: GnmExpr *res = malloc (sizeof (GnmExprBinary)); res->binary.oper = op; return res; is that also invalid? I think that pretty much models what GCC does in its sources, not allocating always the whole size of the union, but sometimes allocating fewer bytes and sometimes more, based on which field of the union is going to be used. Malloc returned pointer should be sufficiently aligned in this case, just will be smaller than the size of the whole union.
[Bug tree-optimization/63659] New: wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63659
Bug ID: 63659
Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk (as well as 4.8.x and 4.9.x) miscompiles the following
code on x86_64-linux at -O2 and -O3 in both 32-bit and 64-bit modes.
This is a regression from 4.7.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/5.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 5.0.0 20141025 (experimental) [trunk revision 216691] (GCC)
$ gcc-trunk -Os small.c; a.out
$ gcc-4.7 -O2 small.c; a.out
$
$ gcc-trunk -O2 small.c
$ ./a.out
Aborted (core dumped)
$
--
int a, b, c, *d = &b, g, h, i;
unsigned char e;
char f;
int
main ()
{
for (; a;)
{
for (a = 0; a; a++)
for (; c; c++)
;
if (i)
break;
}
char j = c, k = -1, l;
l = g = j >> h;
f = l == 0 ? k : k % l;
e = 0 ? 0 : f;
*d = e;
if (b != 255)
__builtin_abort ();
return 0;
}
[Bug tree-optimization/63659] [4.8/4.9/5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63659 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-27 CC||jakub at gcc dot gnu.org, ||uweigand at gcc dot gnu.org Target Milestone|--- |4.8.4 Summary|wrong code at -O2 and -O3 |[4.8/4.9/5 Regression] |on x86_64-linux-gnu |wrong code at -O2 and -O3 ||on x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r186278.
[Bug c/63645] Incorrect code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645 --- Comment #21 from Andreas Schwab --- This is only valid if the object is of the union type (union _GnmExpr) (§6.5.2.3#6: "if the union object currently contains one of these structures").
[Bug rtl-optimization/63659] [4.8/4.9/5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63659 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target||x86_64-unknown-linux-gnu Component|tree-optimization |rtl-optimization --- Comment #2 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #1) > Started with r186278. Then either a target specific issue or an RTL opt issue. Moving to rtl-opt for now.
[Bug c/63645] Incorrect code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645 --- Comment #22 from M Welinder --- >Given > > GnmExprBinary res; > GnmExpr const *expr = (GnmExpr *)&res; > >the C standard does not define where the result of the conversion points; How do you read C99's Section 6.5 #7, then? Doesn't that tell me I can access my GnmExprBinary via an lvalue that has a union type that includes a GnmExprBinary member. GnmExpr is such a union type. Specifically, I read the section as allowing use of the lvalue *expr to access (*expr).binary
[Bug rtl-optimization/63659] [4.8/4.9/5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63659
--- Comment #3 from Jakub Jelinek ---
Seems this is a REE bug. Before REE pass, we have:
(insn 4 27 76 6 (set (reg/v:QI 0 ax [orig:59 k ] [59])
(const_int -1 [0x])) pr63659.c:18 66 {*movqi_internal}
(expr_list:REG_EQUAL (const_int -1 [0x])
(nil)))
...
(insn 46 44 80 9 (set (reg:SI 0 ax [orig:85 f.10 ] [85])
(zero_extend:SI (reg/v:QI 0 ax [orig:59 k ] [59]))) pr63659.c:20 118
{*zero_extendqisi2}
(nil))
...
(insn 47 80 48 9 (set (mem:SI (reg/f:DI 1 dx [orig:84 d ] [84]) [3 *d.11_19+0
S4 A32])
(reg:SI 0 ax [orig:85 f.10 ] [85])) pr63659.c:20 64 {*movsi_internal}
(nil))
REE changes that to:
(insn 4 27 76 6 (set (reg:SI 0 ax)
(const_int 255 [0xff])) pr63659.c:18 64 {*movsi_internal}
(expr_list:REG_EQUAL (const_int -1 [0x])
(nil)))
...
(insn 47 80 48 9 (set (mem:SI (reg/f:DI 1 dx [orig:84 d ] [84]) [3 *d.11_19+0
S4 A32])
(reg:SI 0 ax [orig:85 f.10 ] [85])) pr63659.c:20 64 {*movsi_internal}
(nil))
and there is a (set (reg:SI 0 ax) (const_int -1)) insn in another block.
CSA pass then hoists (set (reg:SI 0 ax) (const_int -1)) before the loop.
The bug is that the REE pass left an invalid REG_EQUAL note which the CSA pass
then used. 0xff value is -1 in QImode, but not after zero-extension.
So I think we'll need to teach the REE pass to adjust or drop
REG_EQUAL/REG_EQUIV notes.
[Bug c/62194] Add deadfield attribute to ignore initializers for a structure field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62194 --- Comment #1 from Josh Triplett --- An additional corner case: a deadfield, even one that has a default value to allow reads of it to work rather than erroring out, must be an rvalue, so that attempts to take the address of it fail.
[Bug c/62194] Add deadfield attribute to ignore initializers for a structure field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62194 --- Comment #2 from Josh Triplett --- One alternative implementation: if GCC supported a "property" attribute, specifying (optional) functions to get or set the property (with compile-time errors if attempting to get/set a property for which the corresponding function does not exist), that would completely address this issue as well: just define a no-op setter and either a constant or non-existent getter.
Re: g++ off-by-one bug in utf16 conversion
This is bug 41698. Please send a patch to gcc-patches, including the addition of a testcase to the testsuite. -- Joseph S. Myers jos...@codesourcery.com
[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #15 from joseph at codesourcery dot com --- On Sun, 26 Oct 2014, Keith.S.Thompson at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 > > --- Comment #14 from Keith Thompson --- > The C standard requires that, if y "happens to immediately follow" > x in the address space, then a pointer just past the end of x shall > compare equal to a pointer to the beginning of y (C99 and C11 6.5.9p6). > > How could I distinguish the current behavior of gcc from the behavior > of a hypothetical C compiler that violates that requirement? In > other words, in what sense does gcc actually obey that requirement? They are not distinguishable (unless by implementation documentation defining what "happens to immediately follow" means for the given implementation - but the meaning of that phrase is unspecified, not implementation-defined, so there is no requirement for implementations to document anything in that regard). "happens to immediately follow" is an intuitive description that explains *why* such pointers are allowed to compare equal at all (to avoid a requirement for otherwise unnecessary padding in common classes of implementations), but can only be observed by the result of a comparison (an observation that is then only valid for that particular comparison). The natural state would be for such pointers to compare unequal. The standard gives latitude for them to compare equal, but there is never an observable requirement that they do, even if some other comparison had that result.
[Bug c/63645] Incorrect code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645 --- Comment #23 from joseph at codesourcery dot com --- On Mon, 27 Oct 2014, jakub at gcc dot gnu.org wrote: > Let's consider if in #c11 you change: > GnmExprBinary *res = malloc (sizeof (GnmExprBinary)); > res->oper = op; > return (GnmExpr*)res; > to: > GnmExpr *res = malloc (sizeof (GnmExprBinary)); > res->binary.oper = op; > return res; > is that also invalid? I think that pretty much models what GCC does in its That's one of the poorly defined cases where it's not clear which object is relevant.
[Bug driver/63660] New: [4.8-4.9+] -Wmaybe-uninitialized false positive with -O1 and more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63660
Bug ID: 63660
Summary: [4.8-4.9+] -Wmaybe-uninitialized false positive with
-O1 and more
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: ed0.88.prez at gmail dot com
Here, this code:
cat bug.i
typedef struct
{
int a;
int b;
int c;
int d;
int e;
int f;
int g;
int h;
int i;
int j;
} X;
X *XX(int);
int G();
static void F()
{
X *x;
int m, n;
int xa, xb, xc, xd, xe, xf, xg, xh, xi, xj;
m = G();
n = G();
if ( n & 1 ) xa = G();
if ( n & 2 ) xb = G();
if ( n & 4 ) xc = G();
if ( n & 32 ) xd = G();
if ( n & 16 ) xe = G();
if ( n & 64 ) xf = G();
if ( n & 256 ) xg = G();
if ( n & 512 ) xh = G();
if ( n & 1024 ) xi = G();
if ( n & 2048 ) xj = G();
if ( m >= 64 ) return;
x = XX(m);
if ( n & 1 ) x->a = xa;
if ( n & 2 ) x->b = xb;
if ( n & 4 ) x->c = xc;
if ( n & 32 ) x->d = xd;
if ( n & 16 ) x->e = xe;
if ( n & 64 ) x->f = xf;
if ( n & 256 ) x->g = xg;
if ( n & 512 ) x->h = xh;
if ( n & 1024 ) x->i = xi;
if ( n & 2048 ) x->j = xj;
}
void H()
{
F();
}
EOF
Compiled with -O1 -Wmaybe-uninitialized (implied by -Wall), reports this
message:
bug.i: In function ‘H’:
bug.i:49:23: warning: ‘xj’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
if ( n & 2048 ) x->j = xj;
^
bug.i:23:42: note: ‘xj’ was declared here
int xa, xb, xc, xd, xe, xf, xg, xh, xi, xj;
^
This code is a very reduced testcase from a large program.
[Bug rtl-optimization/63620] RELOAD lost SET_GOT dependency on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620 --- Comment #12 from Jeffrey A. Law --- The more I watch the %ebx PIC problems, the more this reminds me of secondary reloads and I wonder if we defined those properly if the right things would happen. This kind of thing has shown up on other architectures. For example, on the PA, if you try to load a symbolic constant into an FP register while generating PIC code, you have to generate a secondary reload using %r1 as a scratch. It's not a perfect match in that we don't need a scratch, but instead the PIC register to be live, but it's pretty damn close. I haven't looked at LRA's handling of secondary reloads, but it may be worth someone's time to do so to see if it can be used to show %ebx as being needed in these cases.
[Bug rtl-optimization/63659] [4.8/4.9/5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63659 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 33820 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33820&action=edit gcc5-pr63659.patch Untested fix.
[Bug c/63645] Incorrect code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645 --- Comment #24 from joseph at codesourcery dot com --- On Mon, 27 Oct 2014, terra at gnome dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645 > > --- Comment #22 from M Welinder --- > >Given > > > > GnmExprBinary res; > > GnmExpr const *expr = (GnmExpr *)&res; > > > >the C standard does not define where the result of the conversion points; > > How do you read C99's Section 6.5 #7, then? It only applies if you have validly obtained lvalues of different types referring to overlapping objects. Sometimes pointer conversions will obtain those; sometimes they won't. The C model of pointer conversions is *not* "pointers point to a particular byte address, and conversions just change the type but not the byte address". It's much more restricted that that. Unless there are particular statements in the C standard that say what the resulting pointer points to (e.g. the statements about conversion from a pointer to a structure to a pointer to its first member, and back, *when you have a structure object in the first place*, or about conversions to pointers to character type), the result is not specified. But if you have a union between float and int, take a pointer to the first member, and cast that pointer to type float *, there is no guarantee that the result is a pointer to the float member, absent a specific statement that defines the result of such a conversion (whereas if you cast indirectly, first to a pointer to the union then to float *, you would get a pointer to the float member). And even when you have pointers to the two members of the union, you are still restricted in using them together (see DR#236) - that is the point at which 6.5#7 comes in. But a simple cast from int * to float * doesn't even get that far - the value of the result is unspecified beyond what you get on converting it back to int *.
[Bug c/62194] Add deadfield attribute to ignore initializers for a structure field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62194 --- Comment #3 from Josh Triplett --- (In reply to Josh Triplett from comment #2) > One alternative implementation: if GCC supported a "property" attribute, > specifying (optional) functions to get or set the property (with > compile-time errors if attempting to get/set a property for which the > corresponding function does not exist), that would completely address this > issue as well: just define a no-op setter and either a constant or > non-existent getter. One issue with this approach: it would require the property mechanism to handle initializers somehow. So, on second thought, I think "deadfield" is still the right way to go.
[Bug target/63661] New: -O2 miscompiles on OSX 10.10 Yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661 Bug ID: 63661 Summary: -O2 miscompiles on OSX 10.10 Yosemite Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vbraun.name at gmail dot com Created attachment 33821 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33821&action=edit Testcase that yields wrong answer when compiled with -O2 The attached selfcontained test_mathieu.c is based on the GSL testsuite. I tried to make it shorter but simple changes like adding printf tend to "fix" it. Compilation fails on OSX 10.10 Yosemite when compiled with -O2: $ gcc -O0 -o test_mathieu test_mathieu.c -lm && ./test_mathieu loop -2.35802 loop 2 loop 2 loop 2 loop 2 $ gcc -O1 -o test_mathieu test_mathieu.c -lm && ./test_mathieu loop -2.35802 loop 2 loop 2 loop 2 loop 2 $ gcc -O2 -o test_mathieu test_mathieu.c -lm && ./test_mathieu loop -2.35802 loop 2.35802 loop 2.35802 loop 2.35802 loop 2.35802 Notes: * The non-optimized values are the correct ones. * Works on linux x86_64 with gcc 4.9.1 (Fedora 21 alpha) * Works with Apple clang
[Bug target/63661] -O2 miscompiles on OSX 10.10 Yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661 --- Comment #1 from Volker Braun --- Created attachment 33822 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33822&action=edit Output of gcc -v
[Bug c++/63582] [5 Regression]: g++.dg/init/enum1.C ... (test for errors, line 12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63582 DJ Delorie changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from DJ Delorie --- Patch committed to r216762.
[Bug target/63661] -O2 miscompiles on OSX 10.10 Yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661 --- Comment #2 from Volker Braun --- Created attachment 33823 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33823&action=edit Preprocessed source
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Jeremy Huddleston Sequoia changed: What|Removed |Added CC||jeremyhu at macports dot org --- Comment #42 from Jeremy Huddleston Sequoia --- The committed patch is incorrect. It makes an invalid assumption which breaks the usage of deployment targets such as 10.9.3. Please instead use the (GPL2) patch that I provided back in June and is available from MacPorts: https://trac.macports.org/browser/trunk/dports/lang/apple-gcc42/files/yosemite-deployment-target.patch I will also attach it, but it is based on gcc-4.2 (I do not intentionally read GPL3 code) and may require modification for usage in newer gcc.
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #43 from Jeremy Huddleston Sequoia --- Created attachment 33824 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33824&action=edit gcc 4.2 based patch which handles tiny version numbers properly
[Bug target/59799] aarch64_pass_by_reference never passes arrays by value, contrary to ABI documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59799 --- Comment #11 from Michael Hudson-Doyle --- Er yes, this was fixed before 4.9.0.
[Bug c++/63658] [4.9/5 Regression] Using class reference as template parameter causes compilation to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63658
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #1 from Daniel Krügler ---
The problem seems not to depend on the friend declaration, therefore a more
reduced example code can be formed:
//--
struct Descriptor {};
template
struct foo
{
void size ();
};
Descriptor g_descriptor = {};
template<> void foo::size()
{
}
//--
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #49 from Igor Zamyatin --- Testing a patch to fix asan failures
[Bug target/63442] [AArch64] ICE with ubsan/overflow-int128.c test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63442 --- Comment #5 from Jiong Wang --- Author: jiwang Date: Mon Oct 27 21:58:59 2014 New Revision: 216765 URL: https://gcc.gnu.org/viewcvs?rev=216765&root=gcc&view=rev Log: PR63442 libgcc_cmp_return_mode not always return word_mode gcc/ PR target/63442 * optabs.c (prepare_cmp_insn): Use "ret_mode" instead of "word_mode". Modified: trunk/gcc/ChangeLog trunk/gcc/optabs.c
[Bug target/63442] [AArch64] ICE with ubsan/overflow-int128.c test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63442 Jiong Wang changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jiong Wang --- fixed by 216765.
[Bug preprocessor/63662] New: __has_include defined but not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662
Bug ID: 63662
Summary: __has_include defined but not implemented
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: andre.mccurdy at linaro dot org
Issue seen with Linaro GCC 4.9-2014.10, but believed to also be present in
upstream gcc 4.9.x
$ i586-rdk-linux-gcc -v
Using built-in specs.
COLLECT_GCC=i586-rdk-linux-gcc
COLLECT_LTO_WRAPPER=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr/libexec/i586-rdk-linux/gcc/i586-rdk-linux/4.9.2/lto-wrapper
Target: i586-rdk-linux
Configured with:
/home/andre/rdk/rdk-master/build-qemux86/tmp/work-shared/gcc-linaro-4.9-r2014.10/gcc-linaro-4.9-2014.10/configure
--build=x86_64-linux --host=x86_64-linux --target=i586-rdk-linux
--prefix=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr
--exec_prefix=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr
--bindir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr/bin/i586-rdk-linux
--sbindir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr/bin/i586-rdk-linux
--libexecdir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr/libexec/i586-rdk-linux
--datadir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr/share
--sysconfdir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/etc
--sharedstatedir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/com
--localstatedir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/var
--libdir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr/lib/i586-rdk-linux
--includedir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr/include
--oldincludedir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr/include
--infodir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr/share/info
--mandir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr/share/man
--disable-silent-rules --disable-dependency-tracking
--with-libtool-sysroot=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux
--enable-clocale=generic --with-gnu-ld --enable-shared --enable-languages=c,c++
--enable-threads=posix --disable-multilib --enable-c99 --enable-long-long
--enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=i586-rdk-linux-
--without-local-prefix --enable-target-optspace --enable-lto --enable-libssp
--disable-bootstrap --disable-libmudflap --with-system-zlib
--with-linker-hash-style=gnu --enable-linker-build-id --with-ppl=no
--with-cloog=no --enable-checking=release --enable-cheaders=c_global
--with-gxx-include-dir=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/qemux86/usr/include/c++/4.9.2
--with-sysroot=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/qemux86
--with-build-sysroot=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/qemux86
--enable-targets=all --enable-poison-system-directories
--with-mpfr=/home/andre/rdk/rdk-master/build-qemux86/tmp/sysroots/x86_64-linux/usr
--with-system-zlib --disable-nls --enable-__cxa_atexit
Thread model: posix
gcc version 4.9.2 20141013 (prerelease) (Linaro GCC 4.9-2014.10)
Issue originally seen when building Qt 5.4 alpha1, which includes references to
__has_include such as:
https://qt.gitorious.org/qt/qtbase/source/8e512fbe0b0f99d80d0cf60cd6187a9a9a5a3eb9:src/corelib/global/qlogging.cpp#L77
Minimal testcase:
$ cat tst.c
#ifdef __has_include
# if __has_include()
#include
# endif
#endif
$ i586-rdk-linux-gcc -c tst.c
tst.c:2:7: error: missing binary operator before token "("
# if __has_include()
^
Related gcc-4_9-branch check-in ( SVN r215998 ):
https://gcc.gnu.org/viewcvs/gcc?limit_changes=0&view=revision&revision=215998
[Bug preprocessor/63662] __has_include defined but not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- 4.9 does not have __has_include, only 5. Linaro must have backported the patch for it.
[Bug preprocessor/63662] __has_include defined but not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662 Andrew Pinski changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Andrew Pinski --- I bet you need -std=c++1y . And also this feature is not fully there for GCC 4.9.
[Bug tree-optimization/63530] GCC generates incorrect aligned store on ARM after the loop is unrolled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63530 --- Comment #5 from carrot at gcc dot gnu.org --- Author: carrot Date: Tue Oct 28 00:20:13 2014 New Revision: 216770 URL: https://gcc.gnu.org/viewcvs?rev=216770&root=gcc&view=rev Log: PR tree-optimization/63530 tree-vect-data-refs.c (vect_create_addr_base_for_vector_ref): Set pointer alignment according to DR_MISALIGNMENT. gcc.dg/vect/pr63530.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr63530.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-vect-data-refs.c
[Bug c/63663] New: [NEON] wrong value when computing the leading zero of int16x4_t type at O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63663
Bug ID: 63663
Summary: [NEON] wrong value when computing the leading zero
of int16x4_t type at O2
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: spf_zju at 126 dot com
the 1.c code is :
#include
#include
int main()
{
int16x4_t vector_int16x4;
int16x4_t vector_res_int16x4;
vector_int16x4 = vdup_n_s16(0);
vector_res_int16x4 = vclz_s16(vector_int16x4);
return vector_res_int16x4[0];
}
compiled with :armeb-linux-gnueabi-gcc -S -O2 -mfloat-abi=softfp -mfpu=neon
1.c
the assembly:
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r0, #32
bx lr
the main should return #16,not #32.
this bug appears in the trunk snapshot 20141026.
[Bug preprocessor/63662] __has_include is not implemented but it is defined, so "#ifdef __has_include" guards are ineffective in blocking usage of __has_include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662 andre.mccurdy at linaro dot org changed: What|Removed |Added Summary|__has_include defined but |__has_include is not |not implemented |implemented but it is ||defined, so "#ifdef ||__has_include" guards are ||ineffective in blocking ||usage of __has_include --- Comment #3 from andre.mccurdy at linaro dot org --- Thanks. I have updated the original summary since it was unclear: The bug is not that the __has_include feature can't be used in 4.9.x. The bug is that __has_include is defined in gcc-4_9-branch, which causes "#ifdef __has_include" be ineffective as a guard to prevent attempts to use the __has_include feature.
