[Bug c/61191] cilkplus ICE on syntax error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61191 --- Comment #6 from Igor Zamyatin izamyatin at gmail dot com --- Thanks!
[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.1 Summary|powerpc fp-bit ices at |[4.9/4.10 Regression] |dwf_regno |powerpc fp-bit ices at ||dwf_regno --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Please specify more exactly the affected target triplet and specify a known-to-work version. Marking as regression for now.
[Bug bootstrap/61326] bootstrap failure of gcc-4.8.3 on ia64-hpux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61326 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-05-27 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Can you attach preprocessed source so we can investigate with a cross compiler?
[Bug ipa/61324] [4.10 Regression] ICE: SIGSEGV at ipa-comdats.c:321 with -fno-use-cxa-atexit -fkeep-inline-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61324 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.10.0
[Bug rtl-optimization/61325] [4.10 regression] aarch64_be build fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61325 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||build Target Milestone|--- |4.10.0
[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102 --- Comment #11 from Sebastian Huber sebastian.hu...@embedded-brains.de --- (In reply to Richard Biener from comment #10) Please specify more exactly the affected target triplet and specify a known-to-work version. Marking as regression for now. A target is for example powerpc-eabispe or powerpc-rtems. Known to work are GCC 4.8.0, 4.8.1, 4.8.2 and 4.8.3.
[Bug c/61328] New: valgrind finds problem in find_bswap_or_nop_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61328 Bug ID: 61328 Summary: valgrind finds problem in find_bswap_or_nop_1 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Created attachment 32859 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32859action=edit C source code I just compiled the attached code with gcc trunk 20140526 with flag -O2 under valgrind and it said ==24014== Conditional jump or move depends on uninitialised value(s) ==24014==at 0xA8F1F5: find_bswap_or_nop_1(gimple_statement_base*, symbolic_number*, int) (tree-ssa-math-opts.c:1918) ==24014==by 0xA8FD14: (anonymous namespace)::pass_optimize_bswap::execute(function*) (tree-ssa-math-opts.c:2034) ==24014==by 0x8AA350: execute_one_pass(opt_pass*) (passes.c:2180) ==24014==by 0x8AAAF7: execute_pass_list_1(opt_pass*) (passes.c:2233) ==24014==by 0x8AADC7: execute_pass_list(function*, opt_pass*) (passes.c:2234) ==24014==by 0x64757C: expand_function(cgraph_node*) (cgraphunit.c:1783) ==24014==by 0x64926C: compile() [clone .part.31] (cgraphunit.c:1917) tree-ssa-math-opts.c:1918 is if (n1.size != n2.size || !source_expr2) return NULL_TREE; Maybe if (!source_expr2) return NULL_TREE; if (n1.size != n2.size) return NULL_TREE; would be better code.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- gcc/java/jcf.h:#define GET_u2(PTR) (((PTR)[0] 8) | ((PTR)[1])) smells like 2014-05-23 Thomas Preud'homme thomas.preudho...@arm.com PR tree-optimization/54733 * tree-ssa-math-opts.c (nop_stats): New bswap_stats structure. ... I've now confirmed that this patch is indeed the culprit. Rainer
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- Thomas, btw, I noticed that you use duplicate dg-options in gcc.dg/optimize-bswapsi-[12].c. Please use dg-additional-options for the s390-*-* case to avoid the duplication. Thanks. Rainer
[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61319 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-27 Component|target |testsuite Ever confirmed|0 |1 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- This test also fails on Centos 5 for the same reason. Reset component to testsuite.
[Bug libstdc++/61329] New: #include regex and _GLIBCXX_DEBUG causes multiple symbol definition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61329 Bug ID: 61329 Summary: #include regex and _GLIBCXX_DEBUG causes multiple symbol definition. Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: pluto at agmk dot net Created attachment 32860 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32860action=edit testcase % g++ t.cpp -Og -g0 -c -std=c++11 -D_GLIBCXX_DEBUG % g++ u.cpp -Og -g0 -c -std=c++11 -D_GLIBCXX_DEBUG % g++ t.o u.o -s -o /dev/null u.o: In function `std::__detail::__7::_State_base::_M_print(std::__7::basic_ostreamchar, std::__7::char_traitschar ) const': u.cpp:(.text+0x0): multiple definition of `std::__detail::__7::_State_base::_M_print(std::__7::basic_ostreamchar, std::__7::char_traitschar ) const' t.o:t.cpp:(.text+0x0): first defined here u.o: In function `std::__detail::__7::_State_base::_M_dot(std::__7::basic_ostreamchar, std::__7::char_traitschar , long) const': u.cpp:(.text+0x1ae): multiple definition of `std::__detail::__7::_State_base::_M_dot(std::__7::basic_ostreamchar, std::__7::char_traitschar , long) const' t.o:t.cpp:(.text+0x1ae): first defined here collect2: error: ld returned 1 exit status % g++ -v Using built-in specs. COLLECT_GCC=/ahome/pawels/dvm/master/toolchain/gcc/sysroot/x86_64-gnu-linux/bin/x86_64-gnu-linux-g++ COLLECT_LTO_WRAPPER=/home/pawels/dvm/master/toolchain/gcc/sysroot/x86_64-gnu-linux/bin/../lib64/gcc/x86_64-gnu-linux/4.9.1/lto-wrapper Target: x86_64-gnu-linux Configured with: ../configure --target=x86_64-gnu-linux --with-arch=x86-64 --prefix=/home/pawels/toolchain.git/gcc/sysroot/x86_64-gnu-linux --with-sysroot=/home/pawels/toolchain.git/gcc/sysroot/x86_64-gnu-linux --libdir=/home/pawels/toolchain.git/gcc/sysroot/x86_64-gnu-linux/lib64 --libexecdir=/home/pawels/toolchain.git/gcc/sysroot/x86_64-gnu-linux/lib64 --with-slibdir=/home/pawels/toolchain.git/gcc/sysroot/x86_64-gnu-linux/lib64 --with-gmp-include=/home/pawels/toolchain.git/gcc/x86_64-gnu-linux/gcc-math-runtime/include --with-gmp-lib=/home/pawels/toolchain.git/gcc/x86_64-gnu-linux/gcc-math-runtime/lib --with-mpfr-include=/home/pawels/toolchain.git/gcc/x86_64-gnu-linux/gcc-math-runtime/include --with-mpfr-lib=/home/pawels/toolchain.git/gcc/x86_64-gnu-linux/gcc-math-runtime/lib --with-mpc-include=/home/pawels/toolchain.git/gcc/x86_64-gnu-linux/gcc-math-runtime/include --with-mpc-lib=/home/pawels/toolchain.git/gcc/x86_64-gnu-linux/gcc-math-runtime/lib --with-linker-hash-style=both --disable-multilib --enable-nls --disable-libssp --disable-libquadmath --disable-libitm --enable-tls --enable-libstdcxx-allocator=new --enable-extern-template --enable-libstdcxx-time=rt --enable-libstdcxx-threads --enable-symvers=gnu-versioned-namespace --disable-libstdcxx-pch --enable-lto --enable-plugin --enable-c99 --enable-long-long --enable-linux-futex --enable-threads=posix --enable-shared --with-pic --enable-gold --enable-libgomp --enable-__cxa_atexit --disable-initfini-array --disable-gnu-unique-object --enable-languages=c,c++ --enable-checking=release --with-long-double-128 --disable-cld --disable-bootstrap Thread model: posix gcc version 4.9.1 20140505 (prerelease) (GCC)
[Bug libstdc++/61329] #include regex and _GLIBCXX_DEBUG causes multiple symbol definition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61329 --- Comment #1 from Pawel Sikora pluto at agmk dot net --- Created attachment 32861 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32861action=edit testcase
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #6 from Thomas Preud'homme thomas.preudhomme at arm dot com --- Sure, I'll push a patch for this as soon as I finish fixing the regressions that poped up due to the change I made to the bswap pass.
[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61319 --- Comment #8 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Tue May 27 08:36:37 2014 New Revision: 210958 URL: http://gcc.gnu.org/viewcvs?rev=210958root=gccview=rev Log: 2014-05-27 Dominique d'Humieres domi...@lps.ens.fr PR testsuite/61319 * c-c++-common/ubsan/float-cast-overflow-1.c: Make the sign of -nan optional. * c-c++-common/ubsan/float-cast-overflow-2.c: Likewise. * c-c++-common/ubsan/float-cast-overflow-4.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c trunk/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-2.c trunk/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-4.c
[Bug libgcc/61152] Missing GCC Runtime Library Exception in some files that are included in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Tue May 27 08:41:24 2014 New Revision: 210959 URL: http://gcc.gnu.org/viewcvs?rev=210959root=gccview=rev Log: PR libgcc/61152 * config/arm/arm-opts.h (License): Add GCC Runtime Library Exception. * config/arm/arm-cores.def (License): Same. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-cores.def trunk/gcc/config/arm/arm-opts.h
[Bug libstdc++/61329] #include regex and _GLIBCXX_DEBUG causes multiple symbol definition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61329 --- Comment #2 from Pawel Sikora pluto at agmk dot net --- _M_dot/_M_print declaration from include/c++/4.9.1/bits/regex_automaton.h needs inline attribute.
[Bug bootstrap/61326] bootstrap failure of gcc-4.8.3 on ia64-hpux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61326 --- Comment #2 from Alexander alm at sibmail dot ru --- Created attachment 32862 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32862action=edit the preprocessed file 1
[Bug bootstrap/61326] bootstrap failure of gcc-4.8.3 on ia64-hpux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61326 --- Comment #3 from Alexander alm at sibmail dot ru --- preprocessed source added in attachment
[Bug c++/56947] [4.7 Regression] Bogus 'XX' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56947 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Blocks||52026 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed that. I suppose rejects-valid is better than wrong-code in some sense but the former only was for C++11 code. If there isn't a safe fix for this issue I'd consider reverting the patch for PR52026.
[Bug target/61330] New: Thumb ICE for case 920507-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61330 Bug ID: 61330 Summary: Thumb ICE for case 920507-1.c Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tony.wang at arm dot com I'm running regression test for the latest GCC trunk for cortex-m0, I run into below ICE, but after I remove the commit at trunk@210901, the test case will pass. How to reproduce: Executing on host: /work/terguo01/trunk-t1/build-native/gcc-final/gcc/xgcc -B/work/terguo01/trunk-t1/build-native/gcc-final/gcc/ /work/terguo01/trunk-t1/src/gcc/gcc/testsuite/gcc.dg/noncompile/920507-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O1 -ffat-lto-objects -S-mthumb -mcpu=cortex-m0 -o 920507-1.s(timeout = 300) spawn /work/terguo01/trunk-t1/build-native/gcc-final/gcc/xgcc -B/work/terguo01/trunk-t1/build-native/gcc-final/gcc/ /work/terguo01/trunk-t1/src/gcc/gcc/testsuite/gcc.dg/noncompile/920507-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O1 -ffat-lto-objects -S -mthumb -mcpu=cortex-m0 -o 920507-1.s^M /work/terguo01/trunk-t1/src/gcc/gcc/testsuite/gcc.dg/noncompile/920507-1.c: In function 'x':^M /work/terguo01/trunk-t1/src/gcc/gcc/testsuite/gcc.dg/noncompile/920507-1.c:5:16: error: invalid register name for 'a'^M /work/terguo01/trunk-t1/src/gcc/gcc/testsuite/gcc.dg/noncompile/920507-1.c:3:1: internal compiler error: in symtab_get_node, at cgraph.h:1021^M 0xc1920c symtab_get_node^M /work/terguo01/trunk-t1/src/gcc/gcc/cgraph.h:1018^M 0xc1920c symtab_get_node^M /work/terguo01/trunk-t1/src/gcc/gcc/varasm.c:1134^M 0xc1920c decl_comdat_group^M /work/terguo01/trunk-t1/src/gcc/gcc/cgraph.h:1629^M 0xc1920c get_block_for_decl^M /work/terguo01/trunk-t1/src/gcc/gcc/varasm.c:1146^M 0xc1cadf make_decl_rtl(tree_node*)^M /work/terguo01/trunk-t1/src/gcc/gcc/varasm.c:1376^M 0x8d6b4f rest_of_decl_compilation(tree_node*, int, int)^M /work/terguo01/trunk-t1/src/gcc/gcc/passes.c:215^M 0x6206a3 expand_one_hard_reg_var^M /work/terguo01/trunk-t1/src/gcc/gcc/cfgexpand.c:1108^M 0x6206a3 expand_one_var^M /work/terguo01/trunk-t1/src/gcc/gcc/cfgexpand.c:1295^M 0x620e0b expand_used_vars_for_block^M /work/terguo01/trunk-t1/src/gcc/gcc/cfgexpand.c:1338^M 0x62c1e6 expand_used_vars^M
[Bug libgcc/61152] Missing GCC Runtime Library Exception in some files that are included in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Tue May 27 09:05:12 2014 New Revision: 210960 URL: http://gcc.gnu.org/viewcvs?rev=210960root=gccview=rev Log: gcc/ Backport from 2014-05-12 mainline r210322. Backport from 2014-05-27 mainline r210959. PR libgcc/61152 * config/arm/arm.h (License): Add GCC Runtime Library Exception. * config/arm/arm-cores.def (License): Same. * config/arm/arm-opts.h (License): Same. * config/arm/aout.h (License): Same. * config/arm/bpabi.h (License): Same. * config/arm/elf.h (License): Same. * config/arm/linux-elf.h (License): Same. * config/arm/linux-gas.h (License): Same. * config/arm/netbsd-elf.h (License): Same. * config/arm/uclinux-eabi.h (License): Same. * config/arm/uclinux-elf.h (License): Same. * config/arm/vxworks.h (License): Same. libgcc/ Backport from 2014-05-27 mainline r210322. PR libgcc/61152 * config/arm/bpabi-lib.h (License): Add GCC Runtime Library Exception. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/arm/aout.h branches/gcc-4_9-branch/gcc/config/arm/arm-cores.def branches/gcc-4_9-branch/gcc/config/arm/arm-opts.h branches/gcc-4_9-branch/gcc/config/arm/arm.h branches/gcc-4_9-branch/gcc/config/arm/bpabi.h branches/gcc-4_9-branch/gcc/config/arm/elf.h branches/gcc-4_9-branch/gcc/config/arm/linux-elf.h branches/gcc-4_9-branch/gcc/config/arm/linux-gas.h branches/gcc-4_9-branch/gcc/config/arm/netbsd-elf.h branches/gcc-4_9-branch/gcc/config/arm/uclinux-eabi.h branches/gcc-4_9-branch/gcc/config/arm/uclinux-elf.h branches/gcc-4_9-branch/gcc/config/arm/vxworks.h branches/gcc-4_9-branch/libgcc/ChangeLog branches/gcc-4_9-branch/libgcc/config/arm/bpabi-lib.h
[Bug target/61330] [4.10 Regression] Thumb ICE for case 920507-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61330 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Target Milestone|--- |4.10.0 Summary|Thumb ICE for case |[4.10 Regression] Thumb ICE |920507-1.c |for case 920507-1.c --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Seems the parser fails to set DECL_HARD_REGISTER on that bogus decl.
[Bug c/61328] valgrind finds problem in find_bswap_or_nop_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61328 --- Comment #1 from Thomas Preud'homme thomas.preudhomme at arm dot com --- *facepalm* Yes indeed. Does this qualify for an obvious fix as per commiting rules?
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #10 from christophe.lyon at st dot com --- Created attachment 32863 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32863action=edit ELF binary file #2 Compiled with arm-none-linux-gnueabi-gcc -O1 -pie -fpie -mthumb -march=armv5t tls-reload-1.c -o tls-reload-1.exe Binutils Linaro 2014.03
[Bug c/61328] valgrind finds problem in find_bswap_or_nop_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61328 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Thomas Preud'homme from comment #1) *facepalm* Yes indeed. Does this qualify for an obvious fix as per commiting rules? Yes.
[Bug c++/61327] Problem with friend template object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61327
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-05-27
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
Reduced:
templatetypename... T
struct A;
templatetypename T
struct AT
{
templatetypename U
void f(U* u) {
u-T::g();
}
};
struct B {
protected:
void g() { }
};
struct C : B {
templatetypename... friend struct A;
};
int main()
{
C c;
AB a;
a.f(c);
}
The partial specialization does not match the friend declaration for some
reason, I think it should do.
[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61319 --- Comment #9 from Uroš Bizjak ubizjak at gmail dot com --- CentOS 5 still fails with: ./float-cast-overflow-1.c:75:7: error: 'LLONG_MIN' undeclared (first use in this function) ./float-cast-overflow-1.c:79:7: error: 'LLONG_MAX' undeclared (first use in this function) ./float-cast-overflow-1.c:84:7: error: 'ULLONG_MAX' undeclared (first use in this function)
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #11 from wangzheyu tony.wang at arm dot com --- Hi, Could you please provide an elf file compiled with arm-none-linux-gnueabi-gcc -Os -g3 -pie -fpie -mthumb -march=armv5t So that we can debug under our hardware and easy to compared with the former one. Thanks a lot. (In reply to christophe.lyon from comment #10) Created attachment 32863 [details] ELF binary file #2 Compiled with arm-none-linux-gnueabi-gcc -O1 -pie -fpie -mthumb -march=armv5t tls-reload-1.c -o tls-reload-1.exe Binutils Linaro 2014.03
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #12 from christophe.lyon at st dot com --- Created attachment 32864 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32864action=edit ELF binary file #3 Compiled with -Os -g3 -pie -fpie -march=armv5t -mthumb
[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61319
--- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org ---
Ah. I hope the following will help:
--- a/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c
+++ b/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c
@@ -5,6 +5,16 @@
#include limits.h
#include float-cast.h
+#if !defined LLONG_MAX defined __LONG_LONG_MAX__
+# define LLONG_MAX __LONG_LONG_MAX__
+#endif
+#if !defined LLONG_MIN defined __LONG_LONG_MAX__
+# define LLONG_MIN (-__LONG_LONG_MAX__ - 1LL)
+#endif
+#if !defined ULLONG_MAX defined __LONG_LONG_MAX__
+# define ULLONG_MAX (__LONG_LONG_MAX__ * 2ULL + 1ULL)
+#endif
+
int
main (void)
{
[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61319
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Marek Polacek from comment #10)
Ah. I hope the following will help:
--- a/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c
+++ b/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c
@@ -5,6 +5,16 @@
#include limits.h
#include float-cast.h
+#if !defined LLONG_MAX defined __LONG_LONG_MAX__
+# define LLONG_MAX __LONG_LONG_MAX__
+#endif
+#if !defined LLONG_MIN defined __LONG_LONG_MAX__
+# define LLONG_MIN (-__LONG_LONG_MAX__ - 1LL)
+#endif
+#if !defined ULLONG_MAX defined __LONG_LONG_MAX__
+# define ULLONG_MAX (__LONG_LONG_MAX__ * 2ULL + 1ULL)
+#endif
+
int
main (void)
{
__LONG_LONG_MAX__ is always defined, no need to test for that.
[Bug c++/57543] decltype needs explicit 'this' pointer in member function declaration of template class with trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57543 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.10.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61319
--- Comment #12 from Marek Polacek mpolacek at gcc dot gnu.org ---
Thus
--- a/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c
+++ b/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c
@@ -5,6 +5,16 @@
#include limits.h
#include float-cast.h
+#ifndef LLONG_MAX
+# define LLONG_MAX __LONG_LONG_MAX__
+#endif
+#ifndef LLONG_MIN
+# define LLONG_MIN (-__LONG_LONG_MAX__ - 1LL)
+#endif
+#ifndef ULLONG_MAX
+# define ULLONG_MAX (__LONG_LONG_MAX__ * 2ULL + 1ULL)
+#endif
+
int
main (void)
{
[Bug libstdc++/61329] #include regex and _GLIBCXX_DEBUG causes multiple symbol definition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61329 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-27 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |4.9.1 Ever confirmed|0 |1
[Bug libstdc++/61329] #include regex and _GLIBCXX_DEBUG causes multiple symbol definition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61329 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Tue May 27 11:14:17 2014 New Revision: 210968 URL: http://gcc.gnu.org/viewcvs?rev=210968root=gccview=rev Log: PR libstdc++/61329 * include/bits/regex_automaton.tcc (_State_base::_M_print): Add inline specifier. (_State_base::_M_dot): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/regex_automaton.tcc
[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61319
--- Comment #13 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Marek Polacek from comment #12)
Thus
--- a/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c
+++ b/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-1.c
Yes, this patch works for me on x86_64-pc-linux-gnu {,-m32} Centos 5.
BTW: IMO, the new defines should be put in float-cast.h, alongside INT128
defines.
Thanks!
[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61319 --- Comment #14 from Marek Polacek mpolacek at gcc dot gnu.org --- Thanks, will post the patch to ML.
[Bug middle-end/61207] Win64 gcc 4.9.0: ICE at -Os compiling some C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61207 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-27 Ever confirmed|0 |1 --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org --- ICE happens in in expand_expr_addr_expr_1 because the result is (reg/v:TI 86 [ func ]), which is obviously no memory. Issue seems here to be that x64 ABI has pre-allocated stack-area on call, so for the first 4 arguments no stack-allocation is necessary. So we might need to specialize allocate_stack_slots_for_args-hook for this target.
[Bug libgcc/61152] Missing GCC Runtime Library Exception in some files that are included in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152 --- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Tue May 27 11:37:49 2014 New Revision: 210969 URL: http://gcc.gnu.org/viewcvs?rev=210969root=gccview=rev Log: PR libgcc/61152 * config/arm/arm.h (License): Add note to COPYING.RUNTIME. * config/arm/arm-cores.def (License): Same. * config/arm/arm-opts.h (License): Same. * config/arm/aout.h (License): Same. * config/arm/bpabi.h (License): Same. * config/arm/elf.h (License): Same. * config/arm/linux-elf.h (License): Same. * config/arm/linux-gas.h (License): Same. * config/arm/netbsd-elf.h (License): Same. * config/arm/uclinux-eabi.h (License): Same. * config/arm/uclinux-elf.h (License): Same. * config/arm/vxworks.h (License): Same. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/aout.h trunk/gcc/config/arm/arm-cores.def trunk/gcc/config/arm/arm-opts.h trunk/gcc/config/arm/arm.h trunk/gcc/config/arm/bpabi.h trunk/gcc/config/arm/elf.h trunk/gcc/config/arm/linux-elf.h trunk/gcc/config/arm/linux-gas.h trunk/gcc/config/arm/netbsd-elf.h trunk/gcc/config/arm/uclinux-eabi.h trunk/gcc/config/arm/uclinux-elf.h trunk/gcc/config/arm/vxworks.h
[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61319 --- Comment #15 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue May 27 11:41:45 2014 New Revision: 210970 URL: http://gcc.gnu.org/viewcvs?rev=210970root=gccview=rev Log: PR testsuite/61319 * c-c++-common/ubsan/float-cast.h: Conditionally define LLONG_MAX, LLONG_MIN, and ULLONG_MAX. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/ubsan/float-cast.h
[Bug libgcc/61152] Missing GCC Runtime Library Exception in some files that are included in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152 --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Tue May 27 11:42:10 2014 New Revision: 210971 URL: http://gcc.gnu.org/viewcvs?rev=210971root=gccview=rev Log: PR libgcc/61152 * config/arm/arm.h (License): Add note to COPYING.RUNTIME. * config/arm/arm-cores.def (License): Same. * config/arm/arm-opts.h (License): Same. * config/arm/aout.h (License): Same. * config/arm/bpabi.h (License): Same. * config/arm/elf.h (License): Same. * config/arm/linux-elf.h (License): Same. * config/arm/linux-gas.h (License): Same. * config/arm/netbsd-elf.h (License): Same. * config/arm/uclinux-eabi.h (License): Same. * config/arm/uclinux-elf.h (License): Same. * config/arm/vxworks.h (License): Same. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/arm/aout.h branches/gcc-4_9-branch/gcc/config/arm/arm-cores.def branches/gcc-4_9-branch/gcc/config/arm/arm-opts.h branches/gcc-4_9-branch/gcc/config/arm/arm.h branches/gcc-4_9-branch/gcc/config/arm/bpabi.h branches/gcc-4_9-branch/gcc/config/arm/elf.h branches/gcc-4_9-branch/gcc/config/arm/linux-elf.h branches/gcc-4_9-branch/gcc/config/arm/linux-gas.h branches/gcc-4_9-branch/gcc/config/arm/netbsd-elf.h branches/gcc-4_9-branch/gcc/config/arm/uclinux-eabi.h branches/gcc-4_9-branch/gcc/config/arm/uclinux-elf.h branches/gcc-4_9-branch/gcc/config/arm/vxworks.h
[Bug testsuite/61319] The tests c-c++-common/ubsan/float-cast-overflow-(1|2|4).c fail on x86_64-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61319 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Marek Polacek mpolacek at gcc dot gnu.org --- I hope this is fixed now.
[Bug target/61044] Computed goto on AVR fails to use word-addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61044 --- Comment #3 from Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot com --- Johann, The primary reason I added the diff relocs was to prevent linker relaxation messing up DWARF line number information - as you know, relaxation can shorten instruction sequences, and the addresses in DWARF then go out of sync. I guess I must add some user documentation about this, but ideally, this is supposed to be transparent to the user - just passing -mrelax to the compiler should work. I turned diff reloc generation on only if -mlink-relax is passed because this is what other ports (xtensa) do, and I wasn't sure of the consequences of resolving every subtraction expression at link time. I tried assembling .word pm(.L3-.L2) with -mlink-relax, but the assembler gave up with an expression too complex error. Like you said, I guess documenting that this is not supported is the way to go.
[Bug other/61321] demangler crash on casts in template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61321 --- Comment #3 from Pedro Alves palves at redhat dot com --- https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02279.html
[Bug other/61233] Demangler crash (GDB PR 16957)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61233 --- Comment #2 from Pedro Alves palves at redhat dot com --- This fixes it: https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02279.html See bug 61321.
[Bug target/61170] FAIL: libgomp.fortran/declare-simd-[12].f90 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61170 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Fixed by revision 210961 (tests now unsupported) Author:uros Date:Tue May 27 09:14:53 2014 UTC (3 hours, 28 minutes ago) Log Message: * testsuite/libgomp.fortran/declare-simd-1.f90: Require vect_simd_clones effective target. * testsuite/libgomp.fortran/declare-simd-2.f90: Ditto.
[Bug libfortran/59513] [4.7/4.8/4.9] Fortran runtime error: Sequential READ or WRITE not allowed after EOF marker, possibly use REWIND or BACKSPACE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59513 giorgio.signorini at unifi dot it changed: What|Removed |Added CC||giorgio.signorini at unifi dot it --- Comment #13 from giorgio.signorini at unifi dot it --- (In reply to Dominique d'Humieres from comment #11) No error with gfortran 4.4.7, 4.5.4, but gfortran 4.6.4 gives the error. So marked as a 4.7/4.8/4.9 regression. When I'll have learnt how to build foil myself, I'll try to do some bisection and some reduction. I think this is connected to bug 44477 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477), which has been fixed in gfortran 4.6. Could it be that the POSITION='APPEND' option acts like a sequence of READs up to EOF, which in gfortran 4.6 did a silent, non-standard BACKSPACE?
[Bug libstdc++/61329] #include regex and _GLIBCXX_DEBUG causes multiple symbol definition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61329 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- fixed for 4.9.1 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Tue May 27 13:12:55 2014 New Revision: 210972 URL: http://gcc.gnu.org/viewcvs?rev=210972root=gccview=rev Log: PR libstdc++/61329 * include/bits/regex_automaton.tcc (_State_base::_M_print): Add inline specifier. (_State_base::_M_dot): Likewise. Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/bits/regex_automaton.tcc
[Bug libstdc++/61329] #include regex and _GLIBCXX_DEBUG causes multiple symbol definition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61329 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- fixed for 4.9.1 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Tue May 27 13:12:55 2014 New Revision: 210972 URL: http://gcc.gnu.org/viewcvs?rev=210972root=gccview=rev Log: PR libstdc++/61329 * include/bits/regex_automaton.tcc (_State_base::_M_print): Add inline specifier. (_State_base::_M_dot): Likewise. Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/bits/regex_automaton.tcc
[Bug target/61331] New: [ARM] GCC build broken since r210964/r210954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61331 Bug ID: 61331 Summary: [ARM] GCC build broken since r210964/r210954 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: christophe.lyon at st dot com Build of GCC trunk is broken since commits 210964 and 210965 for ARM targets. $ /work1/lyon/Work/ARM/Linaro/builds/gcc-fsf-trunk/obj-arm-none-linux-gnueabihf/gcc1/./gcc/xgcc -B/work1/lyon/Work/ARM/Linaro/builds/gcc-fsf-trunk/obj-arm-none-linux-gnueabihf/gc\ c1/./gcc/ -B/work1/lyon/Work/ARM/Linaro/builds/gcc-fsf-trunk/tools/arm-none-linux-gnueabihf/bin/ -B/work1/lyon/Work/ARM/Linaro/builds/gcc-fsf-trunk/tools/arm-none-linux-gnueabihf\ /lib/ -g -O2-fPIC -fno-inline -g -fbuilding-libgcc -fno-stack-protector -fPIC -fno-inline -o unwind-arm.o -fexceptions -c unwind-arm.i -fvisibility=hidden /work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/libgcc/config/arm/unwind-arm.c: In function '_Unwind_VRS_Pop': /work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/libgcc/config/arm/unwind-arm.c:446:1: internal compiler error: in lra_update_insn_recog_data, at lra.c:1363 } ^ 0x86af74 lra_update_insn_recog_data(rtx_def*) /work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trun/gcc/lra.c:1362 0x881692 eliminate_regs_in_insn /work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/lra-eliminations.c:1077 0x881c44 process_insn_for_elimination /work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/lra-eliminations.c:1344 0x881c44 lra_eliminate(bool,bool) /work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/lra-eliminations.c:1408 0x87bc0a lra_constraints(bool) /work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/lra-constraints.c:4049 0x86c84c lra(_IO_FILE*) /work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/lra.c:2332 0x82b80e do_reload /work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/ira.c:5444 0x82b80e execute /work1/lyon/Work/ARM/Linaro/sources/gcc-fsf/trunk/gcc/ira.c:5605 GCC configured with --target=arm-none-linux-gnueabihf --disable-nls --without-headers --with-newlib --disable-shared --disable-threads --disable-libssp --disable-libgomp --disable-libmudflap --disable-libatomic --without-libquadmath --disable-libquadmath --enable-languages=c --with-float=hard --enable-build-with-cxx --with-mode=arm --with-cpu=cortex-a9 --with-fpu=neon
[Bug target/61331] [ARM] GCC build broken since r210964/r210954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61331 --- Comment #1 from christophe.lyon at st dot com --- Created attachment 32865 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32865action=edit unwind-arm.i
[Bug target/61202] gcc generates invalid sqdmulh instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61202 java4ada at yahoo dot com changed: What|Removed |Added CC||java4ada at yahoo dot com --- Comment #5 from java4ada at yahoo dot com --- Will this bug cover 4.8.x as well? (or file separate bug for 4.8.x)
[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot med.uc.edu --- Comment #5 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Andrew Pinski from comment #3) Still does not matter, the compiler is broken and should be reported to Apple. The time for work around in broken compilers is so 90s and really should not be done. This is clang being broken and really should be fixed there instead. Is the object here to burn all bridges with the darwin target and leave those users only the option of using llvm based compilers as of gcc 4.10? While I realize you are all frustrated with the abandonment of post-GPLv2 tools in darwin., this action simply makes it extremely easy for Apple to depreciate their ancient gas assembler in the next Xcode for darwin14 since Apple can rightly say that FSF gcc no longer bootstraps on darwin anyway. I am certain that gas will be depreciated from some future darwin but hopefully will be replaced by a stand-alone assembler based on the clang built-in assembler. However, if FSF gcc starts to get overly self-self-rightous about the compiler details of clang, we might as well fold up our tents on the darwin target. ps Be careful what you wish for. I just updated the llvm34-3.4.1-0e package in fink to use the openmp svn trunk and a back port of the current clang-omp github based on clang 3.4. The resulting clang/clang++ compilers have excellent OpenMP performance defaulted to -fopenmp as -liomp5 rather than -lgomp. http://fink.9193.n7.nabble.com/llvm34-3-4-1-0e-and-OpenMP3-1-Validation-tt46118.html While you are still lucky that there has been little effort on a fortran llvm-based compiler, the rest is a work in rapid progress. So go ahead and dismiss that user base if that is what you desire.
[Bug c++/13590] [DR39] Non-existing ambiguity when inheriting through virtuals two identical using declarations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13590
darkdragon-001 at web dot de changed:
What|Removed |Added
CC||darkdragon-001 at web dot de
--- Comment #20 from darkdragon-001 at web dot de ---
I think that non abiguous cases should be allowed. My basic inheritance
structure is as follows:
01 class Base {
02 public:
03virtual void foo() { cout Base endl; }
04 };
05 class A : public Base {
06public:
07//using Base::foo;
08//virtual void foo() { cout A endl; }
09//virtual void foo() { Base::foo(); }
10 };
11 class B : public Base {
12public:
13//virtual void foo() { cout B endl; }
14 };
15 class AB : public A,B {
16public:
17 //using Base::foo;
18//using A::foo;
19//using A::Base::foo;
20//virtual void foo() { cout AB endl; }
21 };
22
23 int main() {
24 //Base *p = new AB;
25 AB *p = new AB;
26 //p-foo();
27
28 return 0;
29 }
Currently only the following case is possible:
0.) uncomment line 09, 18, 26 which is the worst option I think
The following cases should be allowed:
1.) uncomment line 24 // virtual and non virtual functions are unambiguous
2.) uncomment line 26 // it is clear to use HW::foo() - both paths same
properties
3.) uncomment line 17 // clear to use HW::foo()
4.) uncomment line 18 (perhaps together with line 07) // clear to use the
inherited A::foo() which inherits from the HW::foo()
5.) change line 11 to class B : private Base { // only A::foo is accessible,
B::foo not
6.) doing the the cases above without virtual
[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315 --- Comment #6 from Jack Howarth howarth at nitro dot med.uc.edu --- I would also add that you are playing with fire here. Currently no company has a motivation to expend money or resources for fortran development on llvm as long as FSF gcc is buildable. If you start removing competing compilers from bootstrapping FSF gcc, it is much more likely that someone will fund such a llvm-based fortran compiler project. You may get some short-term satisfaction from walling off FSF-gcc from clang, the long-term outcome for the FSF gcc project might not be so happy.
[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- A patch has been posted at https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02173.html.
[Bug target/61296] Excessive alignment in ix86_data_alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- The comdat definition needs to the biggest alignment generated by any compilers.
[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315 --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Jack Howarth from comment #5) (In reply to Andrew Pinski from comment #3) Still does not matter, the compiler is broken and should be reported to Apple. The time for work around in broken compilers is so 90s and really should not be done. This is clang being broken and really should be fixed there instead. Is the object here to burn all bridges with the darwin target and leave those users only the option of using llvm based compilers as of gcc 4.10? Well they burned a bridge with saying to the user of their front-end they support GNU C when they do not.
[Bug rtl-optimization/61222] [4.10 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu in decompose, at rtl.h:1456
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61222 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Fixed on trunk.
[Bug c++/61327] Problem with friend template object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61327
--- Comment #2 from Pavel isak50 at mail dot ru ---
// Clang compiles without errors.
class B {
protected:
void f() {}
};
template typename...
struct S;
template typename R
struct SR{
template typename T
static void caller(T *p) {p-B::f();} // error: 'void B::f()' is
protected
//static void caller(T *p) {p-f();}// Ok
};
class Q : B{
template typename... friend struct S;
};
int main(){
Q q;
Sint::caller(q);
return 0;
}
[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315 --- Comment #9 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Andrew Pinski from comment #8) Is the object here to burn all bridges with the darwin target and leave those users only the option of using llvm based compilers as of gcc 4.10? Well they burned a bridge with saying to the user of their front-end they support GNU C when they do not. Well it is kind of late in the game to decide that this is a show-stopper for supporting any target which uses clang as the system compiler. At this point closing bug reports and refusing to even discuss a simple workaround via preprocessor statements in FSF gcc bugzilla just looks petty.
[Bug c++/13590] [DR39] Non-existing ambiguity when inheriting through virtuals two identical using declarations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13590
--- Comment #21 from Jonathan Wakely redi at gcc dot gnu.org ---
Since I'm not sure if any of the examples here are meant to be accepted (some
definitely aren't) here's the example from the standard which should compile:
struct A { int x; };// S(x,A) = { { A::x }, { A }}
struct B { float x; }; // S(x,B) = { { B::x }, { B }}
struct C: public A, public B { }; // S(x,C) = { invalid, { A in C, B in C } }
struct D: public virtual C { }; // S(x,D) = S(x,C)
struct E: public virtual C { char x; }; // S(x,E) = { { E::x }, { E }}
struct F: public D, public E { }; // S(x,F) = S(x,E)
int main() {
F f;
f.x = 0; // OK, lookup finds E::x
}
[Bug libobjc/61332] New: libobjc unsafe malloc use instead objc_malloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61332
Bug ID: 61332
Summary: libobjc unsafe malloc use instead objc_malloc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libobjc
Assignee: unassigned at gcc dot gnu.org
Reporter: max at cert dot cx
Hi,
I have found interesting examples of dynamic memory allocation use in libobjc
libobjc/selector.c -
SEL *
sel_copyTypedSelectorList (const char *name, unsigned int
*numberOfReturnedSelectors)
{
unsigned int count = 0;
SEL *returnValue = NULL;
sidx i;
if (name == NULL)
{
if (numberOfReturnedSelectors)
*numberOfReturnedSelectors = 0;
return NULL;
}
objc_mutex_lock (__objc_runtime_mutex);
/* Count how many selectors we have. */
i = (sidx) objc_hash_value_for_key (__objc_selector_hash, name);
if (i != 0)
{
struct objc_list *selector_list = NULL;
selector_list = (struct objc_list *) sarray_get_safe
(__objc_selector_array, i);
/* Count how many selectors we have. */
{
struct objc_list *l;
for (l = selector_list; l; l = l-tail)
count++;
}
if (count != 0)
{
/* Allocate enough memory to hold them. */
returnValue = (SEL *)(malloc (sizeof (SEL) * (count + 1)));
===
/* Copy the selectors. */
{
unsigned int j;
for (j = 0; j count; j++)
{
returnValue[j] = (SEL)(selector_list-head);
===
selector_list = selector_list-tail;
}
returnValue[j] = NULL;
libobjc/selector.c -
or
libobjc/ivars.c -
struct objc_ivar ** class_copyIvarList (Class class_, unsigned int
*numberOfReturnedIvars)
{
unsigned int count = 0;
struct objc_ivar **returnValue = NULL;
struct objc_ivar_list* ivar_list;
if (class_ == Nil || CLS_IS_IN_CONSTRUCTION (class_))
{
if (numberOfReturnedIvars)
*numberOfReturnedIvars = 0;
return NULL;
}
/* Count how many ivars we have. */
ivar_list = class_-ivars;
count = ivar_list-ivar_count;
if (count != 0)
{
unsigned int i = 0;
/* Allocate enough memory to hold them. */
returnValue = (struct objc_ivar **)(malloc (sizeof (struct objc_ivar *) *
(count + 1))); ==
/* Copy the ivars. */
for (i = 0; i count; i++)
returnValue[i] = (ivar_list-ivar_list[i]); ===
returnValue[i] = NULL;
}
libobjc/ivars.c -
or
libobjc/protocols.c -
Protocol **
objc_copyProtocolList (unsigned int *numberOfReturnedProtocols)
{
unsigned int count = 0;
Protocol **returnValue = NULL;
node_ptr node;
objc_mutex_lock (__protocols_hashtable_lock);
/* Count how many protocols we have. */
node = objc_hash_next (__protocols_hashtable, NULL);
while (node)
{
count++;
node = objc_hash_next (__protocols_hashtable, node);
}
if (count != 0)
{
unsigned int i = 0;
/* Allocate enough memory to hold them. */
returnValue = (Protocol **)(malloc (sizeof (Protocol *) * (count + 1)));
===
/* Copy the protocols. */
node = objc_hash_next (__protocols_hashtable, NULL);
===
while (node)
{
returnValue[i] = node-value;
libobjc/protocols.c -
Why malloca() was used instead objc_malloc()? Is there any sensible reason?
In terms of safety, if you can create a properly buffer length (FREE_MEMORY / 2
+1) may end up to crash at this point.
http://cwe.mitre.org/data/definitions/252.html
Thanks for taking the time.
Maksymilian
http://cifrex.org
[Bug c++/61182] [4.9/4.10 Regression] Forming pointer to qualified function type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #12 from Jason Merrill jason at gcc dot gnu.org --- So, not a GCC bug.
[Bug c/56724] sub-optimal location in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 --- Comment #11 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue May 27 20:14:22 2014 New Revision: 210980 URL: http://gcc.gnu.org/viewcvs?rev=210980root=gccview=rev Log: PR c/56724 * c-typeck.c (convert_arguments): Get location of a parameter. Change error and warning calls to error_at and warning_at. Pass location of a parameter to it. Call warning_at with OPT_Wtraditional_conversion. (convert_for_assignment): Add parameter to WARN_FOR_ASSIGNMENT and WARN_FOR_QUALIFIERS. Pass expr_loc to those. * gcc.dg/pr56724-1.c: New test. * gcc.dg/pr56724-2.c: New test. * gcc.dg/wtr-conversion-1.c: Use -Wtraditional-conversion instead of -Wtraditional. * gcc.dg/dfp/wtr-conversion-1.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/pr56724-1.c trunk/gcc/testsuite/gcc.dg/pr56724-2.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/dfp/wtr-conversion-1.c trunk/gcc/testsuite/gcc.dg/wtr-conversion-1.c
[Bug libobjc/61332] libobjc unsafe malloc use instead objc_malloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61332 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- The difference between malloc and objc_malloc is minor when not using GC. In fact the program will crash is malloc returns NULL anyways.
[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315 mrs at gcc dot gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org Resolution|INVALID |DUPLICATE --- Comment #10 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- This is a duplicate of 61146. Non-technical content to gnu.misc.discuss please. *** This bug has been marked as a duplicate of bug 61146 ***
[Bug other/61146] wide-int error when building GCC with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146 mrs at gcc dot gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #5 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- *** Bug 61315 has been marked as a duplicate of this bug. ***
[Bug other/61146] wide-int error when building GCC with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146 mrs at gcc dot gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|ASSIGNED Last reconfirmed||2014-05-27 CC||mrs at gcc dot gnu.org Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #6 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- Don't worry, gcc will build with clang.
[Bug other/61146] wide-int error when building GCC with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146 --- Comment #7 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- Patch posted https://gcc.gnu.org/ml/gcc/2014-05/msg00316.html
[Bug libobjc/61332] libobjc unsafe malloc use instead objc_malloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61332
--- Comment #2 from Maksymilian A max at cert dot cx ---
It seems that we have two problems here:
1 The first is memory allocation without GC_malloc (when GC used)
2 If OBJC_WITH_GC is not definied, objc_malloc() also check result of malloc()
-
objc_malloc (size_t size)
{
void *res = (void *)(malloc (size));
if (! res)
_objc_abort (Virtual memory exhausted\n);
return res;
}
-
related to
https://www.securecoding.cert.org/confluence/display/cplusplus/EXP34-CPP.+Ensure+a+null+pointer+is+not+dereferenced
Thank you for your attention
Maksymilian Arciemowicz
http://cifrex.org
[Bug target/60732] FAIL: g++.dg/ext/altivec-7.C -std=* scan-assembler _Z3fooDv*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60732 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-27 Ever confirmed|0 |1 --- Comment #6 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #5) Mike, what do you think is the best solution here? We could use Dominique's patch with a comment to the effect that New-ABI symbols are always emitted on Linux, but only with -fabi-version=4 or later on Darwin. We could revert my change and hardcode -fabi-version=2 for all targets. Or we could take the suggestion from your original review email and duplicate the test into new-ABI and old-ABI versions, and do both of those. I am in favor of the duplicated test. It looks to me like the ELF toolchain is emitting a non-weak alias for the alternate symbol. We don't (currently) support that in Darwin (and it's pretty unlikely we will given ld64's atom rules). Therefore, I concur that the correct action is to have two tests - one for each ABI and run both tests on all targets.
[Bug libgomp/61333] New: potential target specific performance issue with libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333 Bug ID: 61333 Summary: potential target specific performance issue with libgomp Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: howarth.at.gcc at gmail dot com CC: jakub at gcc dot gnu.org While benchmarking the new openmp/clang-omp support against gcc/libgomp on x86_64-apple-darwin13, I noticed a potential performance issue in gcc/libgomp on darwin. Using the attached heated_plate_openmp.c and heated_plate_gcc.sh shell script, I am seeing reproducible timing on darwin that ratio to the timing for one thread as.. gcc 4.8.3 1:1.90:3.31 gcc 4.9.0 1:1.90:3.30 clang 2.4 1:1.99:3.71 compared to Fedora 15 linux gcc 4.6.3 1:1.99:3.92 This is where the timings for the one, two and four OMP processes are normalized to the timing for one OMP process. Unfortunately I don't have access to gcc 4.8.3 or 4.9.0 to test on linux. The timings are reproducible and suggest that darwin may have a performance issue for higher number of OMP threads.
[Bug libgomp/61333] potential target specific performance issue with libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333 --- Comment #1 from Jack Howarth howarth.at.gcc at gmail dot com --- Created attachment 32866 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32866action=edit heated_plate_openmp.c test code
[Bug libgomp/61333] potential target specific performance issue with libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333 --- Comment #2 from Jack Howarth howarth.at.gcc at gmail dot com --- Created attachment 32867 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32867action=edit heated_plate_gcc.sh shell script to collect timings
[Bug libgomp/61333] potential target specific performance issue with libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333 --- Comment #3 from Jack Howarth howarth.at.gcc at gmail dot com --- FYI, the timings on clang are for clang 3.4.1 with a merge of current clang-omp github commit f9e2fd7640f8fc06ebe1ef2f065c6158f6b4b6ef and openmp svn trunk from llvm.org at r208472/
[Bug libgomp/61333] potential target specific performance issue with libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333
--- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org ---
The reason why GCC on linux is better is because it uses the futex syscall to
have better locking (lower overhead). See config/linux/{mutex,lock}.c.
While on Darwin, it directly calls into pthread_mutex calls.
[Bug middle-end/58670] asm goto miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670 David gccbugzilla at limegreensocks dot com changed: What|Removed |Added CC||gccbugzilla@limegreensocks. ||com --- Comment #5 from David gccbugzilla at limegreensocks dot com --- What's the status here? While there was a checkin (r203383 r203384), this sample code still does not work correctly (4.9.0 x86_64-w64-mingw32). The fall-thru case works, but if the jump inside the asm is taken, eax does not get set to zero when it clearly should. My -O2 output is: 004014e0 foo: 4014e0:test ecx,ecx 4014e2:movDWORD PTR [rsp+0x10],edx 4014e6:jne4014f3 foo+0x13 4014e8:btsDWORD PTR [rsp+0x10],0x1 4014ee:jb 401500 foo+0x20 4014f0:xoreax,eax 4014f2:ret 4014f3:moveax,0xfffd 4014f8:nopDWORD PTR [rax+rax*1+0x0] 401500:repz ret 401502:data32 data32 data32 data32 nop WORD PTR cs:[rax+rax*1+0x0]
[Bug lto/61334] New: [4.10 Regression] lto-cgraph.c:976:68: error: 'strnlen' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61334 Bug ID: 61334 Summary: [4.10 Regression] lto-cgraph.c:976:68: error: 'strnlen' was not declared in this scope Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/opt/gnu/gcc/gmp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace-o lto-streamer.o -MT lto-streamer.o -MMD -MP -MF ./.deps/lto-streamer.TPo ../../gcc/gcc/lto-streamer.c ../../gcc/gcc/lto-cgraph.c: In function 'tree_node* read_comdat_group(lto_input_block*)': ../../gcc/gcc/lto-cgraph.c:976:68: error: 'strnlen' was not declared in this scope make[3]: *** [lto-cgraph.o] Error 1
[Bug libgomp/61333] potential target specific performance issue with libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333 --- Comment #5 from Jack Howarth howarth.at.gcc at gmail dot com --- It would be interesting to find out what Intel openmp is doing differently on darwin since it is significantly faster on four threads.
[Bug libgomp/61333] potential target specific performance issue with libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333 --- Comment #6 from Jack Howarth howarth.at.gcc at gmail dot com --- There is a call to pthread_cond_timedwait() in the libiomp5 implementation but I don't see any such calls in libgomp. Perhaps this is the related to the increased performance in libiomp5 on darwin?
[Bug libgomp/61333] potential target specific performance issue with libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61333 --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Jack Howarth from comment #6) There is a call to pthread_cond_timedwait() in the libiomp5 implementation but I don't see any such calls in libgomp. Perhaps this is the related to the increased performance in libiomp5 on darwin? I also see direct use of spin locks rather than calling into the pthread library. Maybe the pthread library has an syscall overhead.
[Bug lto/61123] With LTO, -fno-short-enums is ignored, resulting in ABI mis-matching in linking.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61123
--- Comment #2 from Hale Wang Hale.Wang at arm dot com ---
(In reply to Richard Biener from comment #1)
All ABI changing options should be also enabled for LTO and they also deserve
handling in lto-opts.c (always stream, not only if explicitely set) and
lto-wrapper.c (diagnose mismatches and force a setting for the link stage).
At least enabling them for LTO is minimally required, like you suggest.
Hi Richard,
I was dealing with the fno-short-enum bug that LTO ignore the options of
fshort-enum and fshort-wchar(fshort-wchar is similar with fshort-enum). I tried
to fix this bug by adding these options to LTO group. And this solution works.
Right now, I am trying to add some test cases to report some error message for
these cases in the previous gcc versions. And these cases will be passed after
I add these options to LTO group.
For the option of fshort-enum, I catch the Tag_ABI_enum_size from the final
executable. And this test case can work very well now.
But for the option of fshort-wchar, if I compile the source files without
-flto option, I can catch the Tag_ABI_PCS_wchar_t from the final executable.
If I add the -flto option to the compile command, the Tag_ABI_PCS_wchar_t is
totally disappeared in the final executable.
So I think this is another bug which means the final executable file (or the
ABI) is different if we add -flto or not.
I generated a minimal example.I have two source files:
wchar_0.c:
#include stddef.h
wchar_t wc0[]=L”abc”;
const wchar_t wc1[]=L”abc”;
wchar_1.c:
#include stddef.h
wchar_t b0[]={ L”abc” };
const wchar_t b1[]={ L”abc” };
Firstly, I compile these files without “-flto”:
$ arm-none-eabi-gcc -fshort-wchar wchar_0.c wchar_1.c -Wl,-Ur -o
without_flto.o -nostdlib -Os
$ arm-none-eabi-readelf -A without_flto.o
Attribute Section: aeabi
File Attributes
Tag_CPU_name: ARM7TDMI
Tag_CPU_arch: v4T
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_ABI_PCS_wchar_t: 2
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: small
Tag_ABI_optimization_goals: Aggressive Size
Then I compile these files with –flto:
$ arm-none-eabi-gcc -fshort-wchar wchar_0.c wchar_1.c -Wl,-Ur -o
with_flto.o -nostdlib -Os –flto
$ arm-none-eabi-readelf -A with_flto.o
Attribute Section: aeabi
File Attributes
Tag_CPU_name: ARM7TDMI
Tag_CPU_arch: v4T
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: small
Tag_ABI_optimization_goals: Aggressive Size
So we can see the Tag_ABI_PCS_wchar_t attribute is totally disappeared.
What do you think about this?
