[Bug c/59073] [4.9 Regression] ICE with missing increment in OpenMP for-loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59073 --- Comment #3 from Tobias Burnus --- (In reply to Tobias Burnus from comment #2) > Untested patch Which doesn't work (or is insufficient).
[Bug c/59100] requesting optimization of safe rotate function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59100 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Yeah, see PR45216 and PR57157. Recognizing n?rotate:x as rotate can be done, but probably not in forwprop or at least not at the same spot as simplify_rotate, because it involves PHIs and different basic blocks. Anyway, if you are going to recommend some idiom, I think the one in PR57157 is better because if it doesn't get optimized into the rotate, it at least doesn't contain any conditionals.
[Bug debug/59105] New: -fdebug-prefix-map doesn't affect DW_AT_comp_dir.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59105 Bug ID: 59105 Summary: -fdebug-prefix-map doesn't affect DW_AT_comp_dir. Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: pluto at agmk dot net Created attachment 31203 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31203&action=edit testcase hi, i'm trying to use -fdebug-prefix-map to reuse (ccache) compilation units across multiple software branches. the first problem was reported as PR58767 and the second one is here. the gcc hardcodes DW_AT_comp_dir when -fdebug-prefix-map is in use and prevents ccache from computing identical checksum/manifest. imo -fdebug-prefix-map should adjust DW_AT_comp_dir in the same way as source name (DW_AT_name). $ ./bug.sh + rm -f '*.o' + CXXFLAGS='-Wall -gno-record-gcc-switches -g2 -gdwarf-4 -c' + cd repo/branch + readlink -m t.cpp + src=/home/users/pawels/bugs/gcc-bug/repo/branch/t.cpp + dirname /home/users/pawels/bugs/gcc-bug/repo/branch/t.cpp + g++ -Wall -gno-record-gcc-switches -g2 -gdwarf-4 -c /home/users/pawels/bugs/gcc-bug/repo/branch/t.cpp '-fdebug-prefix-map=/home/users/pawels/bugs/gcc-bug/repo/branch/=' + objdump -g t.o + grep -E DW_AT_name.+cpp <11> DW_AT_name: (indirect string, offset: 0x0): t.cpp + objdump -g t.o + grep -E DW_AT_comp_dir.+string <15> DW_AT_comp_dir: (indirect string, offset: 0x14c): /home/users/pawels/bugs/gcc-bug/repo/branch + cd ../..
[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937 --- Comment #9 from Yury Gribov --- Created attachment 31204 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31204&action=edit Repro Just occured to me that I forgot to attach a reprocase, so doing this now. @Evegeniy: could you check whether this reproduces under Android/Darwin?
[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #14 from Markus Trippelsdorf ---
The 'kernel' case passes a NULL pointer to qsort:
% < test.i
struct relocs {
int *offset;
};
static struct relocs a;
void qsort(void *, int) __attribute__((__nonnull__));
void die(int *p1, ...) {}
void sort_relocs(struct relocs *p1) { qsort(p1->offset, 0); }
int main() {
sort_relocs(&a);
return 0;
}
[Bug target/59101] [4.7/4.8/4.9 Regression] integer wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59101 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-13 CC||jakub at gcc dot gnu.org Component|c |target Target Milestone|--- |4.7.4 Summary|integer wrong code bug |[4.7/4.8/4.9 Regression] ||integer wrong code bug Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Sounds to be a bug in the x86_64 *anddi_2 pattern. If the constant is > 0 and has bit 31 set, then we can't match CCNOmode, just CCZmode.
[Bug sanitizer/55353] [asan] the flag for asan should match the one used in clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55353 Yury Gribov changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #4 from Yury Gribov --- Could someone close this? Was fixed in r193702
[Bug sanitizer/59106] New: Failure to link against static libasan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106
Bug ID: 59106
Summary: Failure to link against static libasan
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: y.gribov at samsung dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
e.gavrin at samsung dot com, jakub at gcc dot gnu.org,
kcc at gcc dot gnu.org, tetra2005 at gmail dot com,
v.garbuzov at samsung dot com
Target: x86_64
When linking sanitized C executable against static libasan I see linker errors:
$ cat repro.i
int main() {
return 0;
}
$ /home/ygribov/install/gcc-master/bin/gcc -g repro.i -fsanitize=address
-static-libasan
/home/ygribov/install/gcc-master/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib64/libasan.a(asan_thread.o):(.data.rel.ro._ZTIN6__asan17AsanThreadContextE[_ZTIN6__asan17AsanThreadContextE]+0x0):
undefined reference to `vtable for __cxxabiv1::__si_class_type_info'
...
collect2: error: ld returned 1 exit status
This is trunk gcc, x86_64.
[Bug sanitizer/55353] [asan] the flag for asan should match the one used in clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55353 Kostya Serebryany changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Kostya Serebryany --- fixed indeed.
[Bug c++/59085] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59085 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot com Severity|blocker |normal
[Bug target/59101] [4.7/4.8/4.9 Regression] integer wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59101 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 31205 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31205&action=edit gcc49-pr59101.patch Untested fix.
[Bug fortran/59107] New: Spurious "Type specified for intrinsic function 'command_argument_count' at (1) is ignored" under -Wsurprising.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59107 Bug ID: 59107 Summary: Spurious "Type specified for intrinsic function 'command_argument_count' at (1) is ignored" under -Wsurprising. Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mathewc at nag dot co.uk > cat test.f90 Program p Integer :: nargs Intrinsic :: command_argument_count nargs = command_argument_count() End > gfortran --version GNU Fortran (GCC) 4.8.2 20131017 (Red Hat 4.8.2-1) > gfortran -Wsurprising test.f90 test.f90:3.37: Intrinsic :: command_argument_count 1 Warning: Type specified for intrinsic function 'command_argument_count' at (1) is ignored
[Bug sanitizer/59106] Failure to link against static libasan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106 --- Comment #1 from Yury Gribov --- Created attachment 31206 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31206&action=edit Proposed patch Does this look sane?
[Bug c++/59066] C++11, 'using' instead of 'typedef' causes a segmentation fault.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59066 --- Comment #3 from Paolo Carlini --- Doesn't look like a front-end issue.
[Bug sanitizer/59106] Failure to link against static libasan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106 --- Comment #2 from Kostya Serebryany --- We should be building libsanitizer with -fno-rtti
[Bug sanitizer/58937] Preloaded libasan segfaults on unsanitized executables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937 --- Comment #10 from Evgeniy Stepanov --- We don't intercept signal() on Android, because there is a friendly crash handler installed by the OS, and we don't need to handle segv ourselves.
[Bug ada/35998] debug info invalid x86_64 DW_AT_byte_size 0xffffffff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35998 --- Comment #8 from Eric Botcazou --- Author: ebotcazou Date: Wed Nov 13 10:07:14 2013 New Revision: 204736 URL: http://gcc.gnu.org/viewcvs?rev=204736&root=gcc&view=rev Log: PR ada/35998 * dwarf2out.c (add_byte_size_attribute): Also use int_size_in_bytes for fields. Do not add the attribute if the size is negative. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug ada/35998] debug info invalid x86_64 DW_AT_byte_size 0xffffffff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35998 Eric Botcazou changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #9 from Eric Botcazou --- Fixed, at long last.
[Bug libfortran/59108] New: ACTION='READ' is using O_CREAT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59108
Bug ID: 59108
Summary: ACTION='READ' is using O_CREAT
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: nmm1 at cam dot ac.uk
Running 'strace -v -e trace=open' on the following program:
PROGRAM Main
OPEN(11,FILE='wombat',ACTION='READ')
OPEN(12,FILE='numbat',ACTION='READ',ACCESS='STREAM')
OPEN(13,FILE='dingbat',ACTION='READ',ACCESS='DIRECT',RECL=8)
END PROGRAM Main
produces:
open("wombat", O_RDONLY|O_CREAT, 0666) = 3
open("numbat", O_RDONLY|O_CREAT, 0666) = 4
open("dingbat", O_RDONLY|O_CREAT, 0666) = 5
Not merely does this create files when the user isn't expecting it,
it fails if the directory or file system is protected against writing.
wheeler$uname -a
Linux wheeler 2.6.37.6-24-desktop #1 SMP PREEMPT 2012-10-18 22:36:08 +0200
x86_64 x86_64 x86_64 GNU/Linux
wheeler$gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/nmm/GCC/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/nmm/GCC --disable-bootstrap
--enable-languages=c,c++,fortran --enable-werror=yes --disable-decimal-float
Thread model: posix
gcc version 4.8.1 (GCC)
[Bug c/35547] -Wparentheses not useful in its current form
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35547 --- Comment #3 from Ian Kirkham --- -Wparentheses is potentially very useful but certainly too broad. I agree that it would help if qualifiers could be added that split the coverage to be able to distinguish between the extremes of 'very probably not intended' from the 'might make intent more explicit'. The former class should include: if (mask & 1 == 1) ... the latter class should include: if (var1 == 1 && var2 == 2 || var1 = 2 && var2 == 1) ... At the moment -Wparentheses will flag both as needing parens to scope the &/&& operator. However, I argue that the latter is at worst a stylistic error because adding the parens as suggested will not change the effect of the code. However in the former case, adding the parens will certainly change the effect of the code as there is a very strong likelihood that the bit-wise AND was expected to have a higher precedence than the comparison operators. Perhaps the suggested -Woperator-precedence qualifier should be two: -Wsafe-operator-precedence flagging all the operator precedence categories -Woperator-precedence flagging just those where bitwise operators are at the same lexical scope as a comparison operator.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #6 from Alexander Potapenko --- The problem is caused by _NSGetEnviron() being called before libSystem is initialized. This happens because some initialization code calls __cxa_atexit() before libSystem_initialize(), and __cxa_atexit() calls __asan_init() and _NSGetEnviron(). The fix is trivial (call the real __cxa_atexit() if asan_inited == 0 instead of calling __asan_init()), but before landing it I'll check why the crash doesn't happen on LLVM (I suspect different linkage order).
[Bug c++/59056] enable_if turns a non-ambiguous template into an ambiguous one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056 Paolo Carlini changed: What|Removed |Added CC||richard-gccbugzilla@metafoo ||.co.uk --- Comment #4 from Paolo Carlini --- Maybe we can ask Richard's opinion about this one too.
[Bug sanitizer/59106] Failure to link against static libasan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106 --- Comment #3 from Yury Gribov --- (In reply to Kostya Serebryany from comment #2) > We should be building libsanitizer with -fno-rtti Ubsan seems to require it: /home/ygribov/gcc/gcc-master/libsanitizer/ubsan/ubsan_type_hash.cc:121:63: error: ‘dynamic_cast’ not permitted with -fno-rtti dynamic_cast(Derived)) ^
[Bug sanitizer/59106] Failure to link against static libasan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106 Alexey Samsonov changed: What|Removed |Added CC||samsonov at google dot com --- Comment #4 from Alexey Samsonov --- Yeah, in LLVM/Clang we build C++-specific part of UBSan with -frtti (and link it to C++ programs only), and the rest sanitizers with -fno-rtti.
[Bug sanitizer/59106] Failure to link against static libasan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106 --- Comment #5 from Kostya Serebryany --- a small part of ubsan does indeed require rtti. See ubsan/CMakeLists.txt (UBSAN_SOURCES vs UBSAN_CXX_SOURCES) The rest of libsanitizer does not and should use -fno-rtti. OMG, I hate having so many different build systems. Long term this will be a maintenance nightmare to support them.
[Bug tree-optimization/59109] New: [4.9 regression] ICE in mark_reachable_handlers, at tree-eh.c:3826
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59109 Bug ID: 59109 Summary: [4.9 regression] ICE in mark_reachable_handlers, at tree-eh.c:3826 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: law at gcc dot gnu.org Target: ia64-*-* Broken by r204708. $ ../../xgcc -B../../ -c -O2 -g -W -Wall -gnatpg -gnata -I- -I../rts -I. -I../../../../gcc/ada ../../../../gcc/ada/make.adb -o make.o ../../../../gcc/ada/make.adb: In function ‘Make.Compile_Sources.Start_Compile_If_Possible’: ../../../../gcc/ada/make.adb:2613:32: warning: ‘Pid’ may be used uninitialized in this function [-Wmaybe-uninitialized] ../../../../gcc/ada/make.adb:2519:10: note: ‘Pid’ was declared here +===GNAT BUG DETECTED==+ | 4.9.0 20131113 (experimental) (ia64-suse-linux) GCC error: | | in mark_reachable_handlers, at tree-eh.c:3826| | Error detected around ../../../../gcc/ada/make.adb:3312:7| #1 0x41257b10 in mark_reachable_handlers ( r_reachablep=, lp_reachablep=) at ../../gcc/tree-eh.c:3826 3826 gcc_assert (gsi_one_before_end_p (gsi));
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #7 from Alexander Potapenko --- If I compile stack-overflow-1.c with 'clang -fsanitize=address -c', the resulting object file can be linked into an executable with either 'clang -fsanitize=address' or 'gcc -fsanitize=address' (this requires declaring "void *__asan_mapping_offset=0x1000;", since the GCC instrumentation pass doesn't insert the mapping offset). The executable linked with Clang works just fine, while the GCC one crashes on the same env_ptr assertion. Clang: $ $CLANG stack-overflow-1.o -fsanitize=address -v && ./a.out ... "/usr/bin/ld" -dynamic -arch x86_64 -macosx_version_min 10.8.0 -o a.out stack-overflow-1.o -lstdc++ /Users/glider/src/asan/llvm/llvm_cmake_build/bin/../lib/clang/3.4/lib/darwin/libclang_rt.asan_osx_dynamic.dylib -lSystem = ==37032==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff5add8aea at pc 0x104e27c93 bp 0x7fff5add89f0 sp 0x7fff5add89e8 ... GCC: $ $GCC stack-overflow-1.o -fsanitize=address -v && ./a.out ... /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.8.5 -weak_reference_mismatches non-weak -o a.out -L/Users/glider/src/gcc-asan/build/inst/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0 -L/Users/glider/src/gcc-asan/build/inst/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/../../.. stack-overflow-1.o -lasan -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v ... ==37029==AddressSanitizer CHECK failed: ../../../../libsanitizer/sanitizer_common/sanitizer_mac.cc:146 "((env_ptr)) != (0)" (0x0, 0x0) This seems to have nothing to do with the linkage order: I've tried to change the order of -l flags in the ld invocation from $GCC, but that didn't work. However when I replaced '-lasan' with the full path to the ASan runtime from the Clang build, it worked fine. So there's some subtle difference between the ASan runtimes compiled when building GCC and Clang.
[Bug sanitizer/59106] Failure to link against static libasan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106 Yury Gribov changed: What|Removed |Added Attachment #31206|0 |1 is obsolete|| --- Comment #6 from Yury Gribov --- Created attachment 31207 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31207&action=edit New patch (In reply to Kostya Serebryany from comment #5) > a small part of ubsan does indeed require rtti. > See ubsan/CMakeLists.txt (UBSAN_SOURCES vs UBSAN_CXX_SOURCES) This is going to be fun because automake does not seem to allow to specify per-file compile flags. > The rest of libsanitizer does not and should use -fno-rtti. Patch attached (without ubsan support for now).
[Bug tree-optimization/59077] ipa-pure-const.c (better_state): comment and code mistmatch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59077 --- Comment #1 from Marc Glisse --- Author: glisse Date: Wed Nov 13 11:55:01 2013 New Revision: 204739 URL: http://gcc.gnu.org/viewcvs?rev=204739&root=gcc&view=rev Log: 2013-11-13 Marc Glisse PR tree-optimization/59077 * ipa-pure-const.c (better_state): Update *state. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-pure-const.c
[Bug sanitizer/59106] Failure to link against static libasan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106 --- Comment #7 from Kostya Serebryany --- Patch looks ok. Please send it in a usual way and someone else (Jakub?) will need to approve it.
[Bug sanitizer/59106] Failure to link against static libasan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106
--- Comment #8 from Jakub Jelinek ---
(In reply to Alexey Samsonov from comment #4)
> Yeah, in LLVM/Clang we build C++-specific part of UBSan with -frtti (and
> link it to C++ programs only), and the rest sanitizers with -fno-rtti.
Can't we just add asm (".weak _Z..."); to the ubsan source that needs C++ and
perhaps check if those symbols are non-NULL, otherwise simply fail the dynamic
type checking?
Then libubsan wouldn't require libstdc++, but, supposedly if you call the ubsan
C++ diagnostics, you'd have libstdc++ or libsupc++ linked in and it would DTRT.
[Bug tree-optimization/59077] ipa-pure-const.c (better_state): comment and code mistmatch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59077 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Marc Glisse --- .
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #8 from Alexander Potapenko --- Clang's libclang_rt.asan_osx_dynamic.dylib depends on the Foundation framework. When I remove that dependency, ASanified programs crash on the same env_ptr assertion.
[Bug tree-optimization/59109] [4.9 regression] ICE in mark_reachable_handlers, at tree-eh.c:3826
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59109 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug tree-optimization/59102] [4.9 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59102 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-13 CC||law at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|ICE on valid code at -Os|[4.9 Regression] ICE on |and above on|valid code at -Os and above |x86_64-linux-gnu|on x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. Use gimple_get_lhst ().
[Bug tree-optimization/59100] requesting optimization of safe rotate function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59100 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-13 Component|c |tree-optimization Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- phiopt would be the pass to recognize new patterns with PHIs, it should be reasonably simple to add there in the value_replacement handler.
[Bug c++/59097] [4.7/4.8/4.9 Regression] ICE with invalid statement expression as array size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59097 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |4.7.4
[Bug sanitizer/59106] Failure to link against static libasan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106
Kostya Serebryany changed:
What|Removed |Added
CC||nlewycky at google dot com
--- Comment #9 from Kostya Serebryany ---
>> Can't we just add asm (".weak _Z...");
The current scheme is more portable
(e.g. I am not sure if Windows supports weak symbols at all)
[Bug sanitizer/59106] Failure to link against static libasan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59106 Yury Gribov changed: What|Removed |Added Attachment #31207|0 |1 is obsolete|| --- Comment #10 from Yury Gribov --- Created attachment 31208 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31208&action=edit Patch with a test Added a test.
[Bug sanitizer/58680] Spurious warnings from libasan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58680 --- Comment #14 from Yury Gribov --- I hate zombie bugs. Can we either fix or wontfix this?
[Bug rtl-optimization/58934] [4.9 Regression]: build fails on cris-elf in reload_cse_simplify_operands for newlib dtoa.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58934 --- Comment #13 from Martin Jambor --- (In reply to r...@cebitec.uni-bielefeld.de from comment #12) > > --- Comment #11 from Martin Jambor --- > [...] > > If anyone is willing to test the patch on any platform but especially > > on those which I could not, I'd be very grateful. Thanks. > > I've now regression-tested the patch on sparc-sun-solaris2.11. > Bootstrap works and I find just a single regression: > > FAIL: gfortran.fortran-torture/execute/pr32604.f90 execution, -O2 > -fbounds-check > > which is reproducible. > > Rainer Thanks a lot. I committed the patch a few moments before reading your comment so I suppose trunk now suffers from this failure. If so, can you please open a bug report? I tried to reproduce it on gcc54 on the compile farm (sparc64-linux) but so far I have failed to even build the gcc itself there :-/
[Bug c++/59110] New: [4.9 Regression] [c++1y] ICE using auto in cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59110 Bug ID: 59110 Summary: [4.9 Regression] [c++1y] ICE using auto in cast Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: reichelt at gcc dot gnu.org The following invalid code snippet (compiled with "-std=c++1y") triggers an ICE on trunk: = int i = *(auto*)0; = bug.cc:1:17: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_conversions, at cp/search.c:2509 int i = *(auto*)0; ^ 0xd3a614 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/gcc/tree.c:9166 0x6bd9f7 tree_check3 ../../gcc/gcc/tree.h:2746 0x6bd9f7 lookup_conversions(tree_node*) ../../gcc/gcc/cp/search.c:2509 0x5493a6 build_user_type_conversion_1 ../../gcc/gcc/cp/call.c:3447 0x54a3c1 implicit_conversion ../../gcc/gcc/cp/call.c:1756 0x54ff6c can_convert_arg_bad(tree_node*, tree_node*, tree_node*, int, int) ../../gcc/gcc/cp/call.c:8960 0x677940 convert_for_assignment ../../gcc/gcc/cp/typeck.c:7992 0x5eff71 digest_init_r ../../gcc/gcc/cp/typeck2.c:1009 0x5f1dc2 digest_init_flags ../../gcc/gcc/cp/typeck2.c:1078 0x5f1dc2 store_init_value(tree_node*, tree_node*, vec**, int) ../../gcc/gcc/cp/typeck2.c:766 0x566066 check_initializer ../../gcc/gcc/cp/decl.c:5739 0x57909d cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int) ../../gcc/gcc/cp/decl.c:6358 0x666c11 cp_parser_init_declarator ../../gcc/gcc/cp/parser.c:16727 0x66837f cp_parser_simple_declaration ../../gcc/gcc/cp/parser.c:8 0x64c7b0 cp_parser_block_declaration ../../gcc/gcc/cp/parser.c:10999 0x670477 cp_parser_declaration ../../gcc/gcc/cp/parser.c:10896 0x66f198 cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:10782 0x670a3a cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:4010 0x670a3a c_parse_file() ../../gcc/gcc/cp/parser.c:31187 0x791cd3 c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1055 Please submit a full bug report, [etc.]
[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555 --- Comment #9 from David Binderman --- (In reply to Markus Trippelsdorf from comment #8) > The following patch seems to fix the issue: Looks good to me. I think it needs to get into the compiler source code somehow. Would posting the patch to gcc-patches be the correct way forward ?
[Bug c++/59110] [4.9 Regression] [c++1y] ICE using auto in cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59110 Volker Reichelt changed: What|Removed |Added Keywords||ice-on-invalid-code Known to work||4.8.0 Target Milestone|--- |4.9.0 Known to fail||4.9.0
[Bug c++/59111] New: [4.9 Regression] [c++11] ICE on invalid usage of auto in return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59111 Bug ID: 59111 Summary: [4.9 Regression] [c++11] ICE on invalid usage of auto in return type Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: reichelt at gcc dot gnu.org The following invalid code snippet (compiled with "-std=c++11") triggers an ICE on trunk: = auto& foo(); int i = foo(); = bug.cc:1:11: warning: 'foo' function uses 'auto' type specifier without trailing return type [enabled by default] auto& foo(); ^ bug.cc:3:13: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_conversions, at cp/search.c:2509 int i = foo(); ^ 0xd3a614 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/gcc/tree.c:9166 0x6bd9f7 tree_check3 ../../gcc/gcc/tree.h:2746 0x6bd9f7 lookup_conversions(tree_node*) ../../gcc/gcc/cp/search.c:2509 0x5493a6 build_user_type_conversion_1 ../../gcc/gcc/cp/call.c:3447 0x54a3c1 implicit_conversion ../../gcc/gcc/cp/call.c:1756 0x54ff6c can_convert_arg_bad(tree_node*, tree_node*, tree_node*, int, int) ../../gcc/gcc/cp/call.c:8960 0x677940 convert_for_assignment ../../gcc/gcc/cp/typeck.c:7992 0x5eff71 digest_init_r ../../gcc/gcc/cp/typeck2.c:1009 0x5f1dc2 digest_init_flags ../../gcc/gcc/cp/typeck2.c:1078 0x5f1dc2 store_init_value(tree_node*, tree_node*, vec**, int) ../../gcc/gcc/cp/typeck2.c:766 0x566066 check_initializer ../../gcc/gcc/cp/decl.c:5739 0x57909d cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int) ../../gcc/gcc/cp/decl.c:6358 0x666c11 cp_parser_init_declarator ../../gcc/gcc/cp/parser.c:16727 0x66837f cp_parser_simple_declaration ../../gcc/gcc/cp/parser.c:8 0x64c7b0 cp_parser_block_declaration ../../gcc/gcc/cp/parser.c:10999 0x670477 cp_parser_declaration ../../gcc/gcc/cp/parser.c:10896 0x66f198 cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:10782 0x670a3a cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:4010 0x670a3a c_parse_file() ../../gcc/gcc/cp/parser.c:31187 0x791cd3 c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1055 Please submit a full bug report, [etc.]
[Bug c++/59112] New: [c++1y] ICE using auto as parameter in local class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59112
Bug ID: 59112
Summary: [c++1y] ICE using auto as parameter in local class
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following (invalid ?) code snippet (compiled with "-std=c++1y") triggers an
ICE on trunk:
void foo()
{
struct A
{
A(auto) {}
};
}
bug.cc: In function 'void foo()':
bug.cc:5:14: internal compiler error: in check_member_template, at
cp/decl2.c:505
A(auto) {}
^
0x61e8e9 check_member_template(tree_node*)
../../gcc/gcc/cp/decl2.c:505
0x59550b finish_member_template_decl(tree_node*)
../../gcc/gcc/cp/pt.c:291
0x63dd49 finish_fully_implicit_template
../../gcc/gcc/cp/parser.c:31363
0x66969e cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:20287
0x6492ad cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:19850
0x6492ad cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:19094
0x6492ad cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19321
0x6492ad cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14215
0x661b57 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11460
0x6681d9 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11050
0x64c7b0 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10999
0x64d8d3 cp_parser_declaration_statement
../../gcc/gcc/cp/parser.c:10646
0x64df47 cp_parser_statement
../../gcc/gcc/cp/parser.c:9387
0x64ec49 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9665
0x64edbe cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9619
0x66248b cp_parser_function_body
../../gcc/gcc/cp/parser.c:18525
0x66248b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18561
0x6662c3 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22593
0x667102 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:22505
0x667102 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16506
Please submit a full bug report, [etc.]
[Bug c++/59113] New: [c++1y] ICE using auto as parameter in local function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59113
Bug ID: 59113
Summary: [c++1y] ICE using auto as parameter in local function
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with "-std=c++1y") triggers an ICE
on trunk:
===
void foo()
{
void bar(auto) {}
}
auto i = 0;
===
bug.cc: In function 'void foo()':
bug.cc:3:18: error: a function-definition is not allowed here before '{' token
void bar(auto) {}
^
bug.cc: At global scope:
bug.cc:6:6: error: 'template auto i' redeclared as different kind
of symbol
auto i = 0;
^
bug.cc:6:6: note: previous declaration of 'auto i'
bug.cc:6:11: internal compiler error: in mangle_decl_string, at
cp/mangle.c:3426
auto i = 0;
^
0x712eff mangle_decl_string
../../gcc/gcc/cp/mangle.c:3426
0x713000 get_mangled_id
../../gcc/gcc/cp/mangle.c:3468
0x713000 mangle_decl(tree_node*)
../../gcc/gcc/cp/mangle.c:3491
0xd3c6d0 decl_assembler_name(tree_node*)
../../gcc/gcc/tree.c:587
0xb2e23e wrapup_global_declaration_2(tree_node*)
../../gcc/gcc/toplev.c:403
0xb2e39b wrapup_global_declarations(tree_node**, int)
../../gcc/gcc/toplev.c:445
0x55e804 wrapup_globals_for_namespace(tree_node*, void*)
../../gcc/gcc/cp/decl.c:882
0x55b7ec walk_namespaces_r
../../gcc/gcc/cp/decl.c:844
0x629884 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4303
Please submit a full bug report, [etc.]
[Bug c++/59114] New: [c++1y] ICE using auto in conversion operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59114
Bug ID: 59114
Summary: [c++1y] ICE using auto in conversion operator
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with "-std=c++1y") triggers an ICE
since GCC 4.8.0:
===
template struct A
{
template operator T();
};
void foo()
{
A<0>().operator auto();
}
===
bug.cc: In function 'void foo()':
bug.cc:8:24: internal compiler error: in push_access_scope, at cp/pt.c:220
A<0>().operator auto();
^
0x591647 push_access_scope
../../gcc/gcc/cp/pt.c:219
0x5e266c fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc/gcc/cp/pt.c:15679
0x54d05c add_template_candidate_real
../../gcc/gcc/cp/call.c:2923
0x548ce9 add_template_candidate
../../gcc/gcc/cp/call.c:3020
0x548ce9 add_candidates
../../gcc/gcc/cp/call.c:5075
0x550617 build_new_method_call_1
../../gcc/gcc/cp/call.c:7698
0x550617 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:7884
0x652842 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6065
0x6548cd cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7100
0x65543f cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:7804
0x65590f cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8042
0x657e63 cp_parser_expression
../../gcc/gcc/cp/parser.c:8204
0x65865e cp_parser_expression
../../gcc/gcc/cp/parser.c:8243
0x65865e cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:9542
0x64df67 cp_parser_statement
../../gcc/gcc/cp/parser.c:9393
0x64ec49 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9665
0x64edbe cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9619
0x66248b cp_parser_function_body
../../gcc/gcc/cp/parser.c:18525
0x66248b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18561
0x6662c3 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22593
Please submit a full bug report, [etc.]
[Bug c++/59115] New: [c++1y] ICE with auto as template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59115
Bug ID: 59115
Summary: [c++1y] ICE with auto as template parameter
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with "-std=c++1y") triggers an ICE
on trunk:
===
template void foo(T, auto) {}
void bar()
{
foo(0, 0);
}
===
bug.cc:1:22: error: 'auto' parameter not permitted in this context
template void foo(T, auto) {}
^
bug.cc: In substitution of 'template, int
, class auto:1> void foo(T, auto:1) [with T = int; = ; int = ; auto:1 = ]':
bug.cc:5:11: required from here
bug.cc:5:11: internal compiler error: in unify, at cp/pt.c:17279
foo(0, 0);
^
0x5d5e3d unify
../../gcc/gcc/cp/pt.c:17279
0x5de566 unify_one_argument
../../gcc/gcc/cp/pt.c:16102
0x5d3493 type_unification_real
../../gcc/gcc/cp/pt.c:16174
0x5e225e fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc/gcc/cp/pt.c:15615
0x54d05c add_template_candidate_real
../../gcc/gcc/cp/call.c:2923
0x548ce9 add_template_candidate
../../gcc/gcc/cp/call.c:3020
0x548ce9 add_candidates
../../gcc/gcc/cp/call.c:5075
0x550062 perform_overload_resolution
../../gcc/gcc/cp/call.c:3816
0x556b5a build_new_function_call(tree_node*, vec**, bool, int)
../../gcc/gcc/cp/call.c:3893
0x6cc2d0 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2274
0x652023 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6094
0x6548cd cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7100
0x65543f cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:7804
0x65590f cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8042
0x657e63 cp_parser_expression
../../gcc/gcc/cp/parser.c:8204
0x65865e cp_parser_expression
../../gcc/gcc/cp/parser.c:8243
0x65865e cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:9542
0x64df67 cp_parser_statement
../../gcc/gcc/cp/parser.c:9393
0x64ec49 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9665
0x64edbe cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9619
Please submit a full bug report, [etc.]
[Bug rtl-optimization/59099] Erroneous register allocation on 32-bit x86 using regparm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59099 H.J. Lu changed: What|Removed |Added CC||jamborm at gcc dot gnu.org Target Milestone|--- |4.9.0 --- Comment #1 from H.J. Lu --- It is caused by r204698. I also saw: FAIL: gcc.dg/ira-shrinkwrap-prep-1.c scan-rtl-dump ira "Split live-range of register" FAIL: gcc.dg/ira-shrinkwrap-prep-1.c scan-rtl-dump ira "Will split live ranges of parameters" FAIL: gcc.dg/ira-shrinkwrap-prep-1.c scan-rtl-dump pro_and_epilogue "Performing shrink-wrapping" FAIL: gcc.dg/ira-shrinkwrap-prep-2.c scan-rtl-dump ira "Split live-range of register" FAIL: gcc.dg/ira-shrinkwrap-prep-2.c scan-rtl-dump ira "Will split live ranges of parameters" FAIL: gcc.dg/ira-shrinkwrap-prep-2.c scan-rtl-dump pro_and_epilogue "Performing shrink-wrapping" on x86-64.
[Bug c++/58533] [c++1y] ICE with auto in function pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58533 Volker Reichelt changed: What|Removed |Added Keywords|ice-on-valid-code |error-recovery, ||ice-on-invalid-code --- Comment #2 from Volker Reichelt --- Sorry, it's not compiled but properly rejected now.
[Bug middle-end/58555] [4.9 Regression] Floating point exception in want_inline_self_recursive_call_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58555 --- Comment #10 from Markus Trippelsdorf --- (In reply to David Binderman from comment #9) > (In reply to Markus Trippelsdorf from comment #8) > > The following patch seems to fix the issue: > > Looks good to me. > > I think it needs to get into the compiler source code somehow. > > Would posting the patch to gcc-patches be the correct way forward ? Yes, but I'd prefer not to. Because without commit rights you'll have to find someone to commit things for you. And the need to repeatedly ping even for trivial patches soon gets ridiculous.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #9 from Jack Howarth --- (In reply to Alexander Potapenko from comment #8) > Clang's libclang_rt.asan_osx_dynamic.dylib depends on the Foundation > framework. When I remove that dependency, ASanified programs crash on the > same env_ptr assertion. Should we just add a CoreFoundation linkage to the creation of libasan.1.dylib in FSF gcc instead?
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #10 from Alexander Potapenko --- This might help, but we don't actually need that dependency. Instead libsanitizer should be updated to r194573.
[Bug c++/59111] [4.9 Regression] [c++11] ICE on invalid usage of auto in return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59111 Richard Biener changed: What|Removed |Added Keywords||ice-on-invalid-code Target Milestone|--- |4.9.0
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #12 from Alexander Potapenko --- That was Foundation, not sure if CoreFoundation also works.
[Bug c++/59080] [4.9 Regression] [c++11] ICE with array of auto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59080 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug tree-optimization/56902] Fails to SLP with mismatched +/- and negatable constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56902 --- Comment #2 from Richard Biener --- Created attachment 31209 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31209&action=edit hack Btw, I also had a patch^Whack, see attached. Also further patches that didn't get merged to take care of vectorizing PR37021 better.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #11 from Jack Howarth --- (In reply to Alexander Potapenko from comment #10) > This might help, but we don't actually need that dependency. > Instead libsanitizer should be updated to r194573. Okay, I assume the missing linkage should be a trivial change like... Index: libsanitizer/asan/Makefile.am === --- libsanitizer/asan/Makefile.am(revision 204618) +++ libsanitizer/asan/Makefile.am(working copy) @@ -43,7 +43,11 @@ libasan_la_LIBADD = $(top_builddir)/sani endif libasan_la_LIBADD += $(LIBSTDCXX_RAW_CXX_LDFLAGS) +if USING_MAC_INTERPOSE +libasan_la_LDFLAGS = -framework CoreFoundation -version-info `grep -v '^\#' $(srcdir)/libtool-version` -lpthread -ldl +else libasan_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` -lpthread -ldl +endif libasan_preinit.o: asan_preinit.o cp $< $@
[Bug c++/59082] [4.7/4.8/4.9 Regression] ICE with duplicate (virtual) base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59082 Richard Biener changed: What|Removed |Added Priority|P3 |P5 Target Milestone|--- |4.7.4
[Bug libstdc++/59087] Issues including complex.h in C++11/1y mode because of C's complex.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59087 --- Comment #4 from Marc Glisse --- Author: glisse Date: Wed Nov 13 15:47:04 2013 New Revision: 204750 URL: http://gcc.gnu.org/viewcvs?rev=204750&root=gcc&view=rev Log: 2013-11-13 Marc Glisse PR libstdc++/59087 * include/ext/pod_char_traits.h: Uglify V, I and S. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/ext/pod_char_traits.h
[Bug libstdc++/59116] New: std::nth_element segfaults by invalidating one of the vector elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59116
Bug ID: 59116
Summary: std::nth_element segfaults by invalidating one of the
vector elements
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: chandraprakashblr at gmail dot com
std::nth_element segfaults by invalidating one of the vector elements.
Note : Replacing nth_element by partial_sort works fine.
Trying nth_element less than 6 also doesn't result in segfault.
Sample program :
#include
#include
#include
#include
int main()
{
for (size_t i(0); i < 1000; ++i) {
std::vector vec;
uint32_t nth_element = 7;
for (size_t i(0); i < 10; ++i) {
vec.push_back(std::rand());
std::cout << " n = " << vec.back() << std::endl;
}
assert((vec.size() >= nth_element));
std::nth_element(vec.begin(), vec.begin() + nth_element, vec.end());
}
}
// commandline: g++ nth_element.cc -std=c++11 -Wall -Wextra
// stack trace
Program received signal SIGSEGV, Segmentation fault.
0x00401fdf in __gnu_cxx::__normal_iterator > >
std::__unguarded_partition<__gnu_cxx::__normal_iterator > >, int>(__gnu_cxx::__normal_iterator > >, __gnu_cxx::__normal_iterator > >, int const&) ()
// system info
OS Ubuntu 13.10 (64 bit)
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/Linaro
4.8.1-10ubuntu8' --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 --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.1 (Ubuntu/Linaro 4.8.1-10ubuntu8)
[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083 --- Comment #15 from Richard Biener --- Note that technically invalid C programs still may be "reasonable". For example writing *0 = 1; and catching that via sigsetjmp/siglongjmp and a signal handler is possible but of course invokes undefined behavior according to the C standard. But yes, if now random "POSIX" programs start failing then that's bad. Does -fnon-call-exceptions exeption handling on SJLJ targets still work? (I suppose we lower to SJLJ only after RTL expansion or we at least still have EH edges around).
[Bug rtl-optimization/59099] [4.9 Regression] Erroneous register allocation on 32-bit x86 using regparm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59099 Martin Jambor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-11-13 Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Jambor --- The test failures should be resolved by http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01461.html The original problem is another matter and I will have a look into it.
[Bug libstdc++/59116] std::nth_element segfaults by invalidating one of the vector elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59116 --- Comment #1 from chandraprakashblr at gmail dot com --- Created attachment 31210 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31210&action=edit preprocessed file of sample program
[Bug libstdc++/59116] std::nth_element segfaults by invalidating one of the vector elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59116 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Marc Glisse --- Already fixed. *** This bug has been marked as a duplicate of bug 58800 ***
[Bug libstdc++/58800] [4.7/4.8/4.9 Regression] std::nth_element segfaults on valid input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58800 Marc Glisse changed: What|Removed |Added CC||chandraprakashblr at gmail dot com --- Comment #26 from Marc Glisse --- *** Bug 59116 has been marked as a duplicate of this bug. ***
[Bug bootstrap/58951] [4.9 regression] cilk build fails due to use of -ldl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58951 Gerald Pfeifer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Gerald Pfeifer --- Fixed now, confirmed on i386-unknown-freebsd10.0 with the following additional change: 2013-11-12 Balaji V. Iyer * Makefile.am (libcilkrts_la_LDFLAGS): Added a check for availability of "-ldl" flag. * configure.ac: Likewise. * configure: Regenerate * Makefile.in: Likewise.
[Bug objc++/59117] New: Is the default constructor generated by the compiler actually called?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59117
Bug ID: 59117
Summary: Is the default constructor generated by the compiler
actually called?
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc++
Assignee: unassigned at gcc dot gnu.org
Reporter: konevaanna2012 at gmail dot com
Dear sirs!
I am Anna Koneva from Moscow, Russia. I have faced with some problem using
XCode 4.6.3 and the LLVM GCC 4.2. I use the following code.
Let's say we have an Objective-C class and a C++ class:
FileObjCClass.h:
#include "CppClass.h"
@interface ObjCClass :NSObject
{
CppClass cppClass;
}
- (void)SomeObjCMethod;
@end
File ObjCClass.mm:
#import "ObjCClass.h"
@implementation ObjCClass
- (void)SomeObjCMethod
{
cppClass.someMethod(43);
}
@end
FileCppClass.h:
classCppClass
{
private:
int _var;
public:
CppClass();
int someMethod(int param);
};
File CppClass.cpp:
#include "CppClass.h"
#include
using namespace std;
CppClass::CppClass()
{
_var = 26;
}
int CppClass::someMethod(int param)
{
cout << "param = " << param << endl << "_var = " << _var << endl;
return param;
}
File main.mm:
#import
#import "ObjCClass.h"
int main(int argc, const char * argv[])
{
ObjCClass *obj = [[ObjCClass alloc]init];
[obj SomeObjCMethod];
[obj release];
return 0;
}
If you switch to «LLVM GCC» from «Apple LLVM compiler» (selected by default
after the creation of the project) a checkbox appears in the project settings
(which is not available for Clang) «Call C++ Default Ctors / Dtors in
Objective-C» (GCC_OBJC_CALL_CXX_CDTORS, -fobjc-call-cxx-cdtors).
Case 1. The checkbox is off.
Results: compiler warnings
«Type 'CppClass' has a user-defined constructor»
«C++ constructors and destructors will not be invoked for Objective-C fields»
The sequence of calls (in order from top to bottom):
— [ObjCClass init]
— [ObjCClass SomeObjCMethod]
CppClass::someMethod(int)
What is interesting, the program succeeds and does not crash.
In this case, our constructor (CppClass::CppClass) actually is not called, but
the object is still created. It seems that the constructor generated by the
compiler is called, but the ours is ignored.
So my question - is it really called the constructor generated by GCC? How can
I prove it? Can I see it in the assembly listing or somehow else? Or am I
totally wrong?
In this case the variable _var has a value 0 both in release and in debug
modes, though in C++ member variables are not initialized by default.
Case 2. If the checkbox is on, then our constructor will be successfully
invoked.
Results:
no compiler warnings
The sequence of calls:
_objc_rootAllocWithZone
object_cxxConstructFromClass(objc_object*, objc_class*)
— [ObjCClass .cxx_construct]
CppClass::CppClass()
— [ObjCClass init]
— [ObjCClass SomeObjCMethod]
CppClass::someMethod(int)
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #8 from Pat Haugen --- (In reply to Kostya Serebryany from comment #7) > Is this fixed by http://gcc.gnu.org/viewcvs?rev=204726&root=gcc&view=rev ? I just tried r204726 on powerpc64-linux and it's failing as follows now. In file included from /home/pthaugen/src/gcc/trunk/gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:17:0: /home/pthaugen/src/gcc/trunk/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:247:72: error: size of array ‘assertion_failed__869’ is negative typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1] ^ /home/pthaugen/src/gcc/trunk/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:241:30: note: in expansion of macro ‘IMPL_COMPILER_ASSERT’ #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__) ^ /home/pthaugen/src/gcc/trunk/gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:739:3: note: in expansion of macro ‘COMPILER_CHECK’ COMPILER_CHECK(sizeof(__sanitizer_##TYPE) == sizeof(TYPE)) ^ /home/pthaugen/src/gcc/trunk/gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:869:1: note: in expansion of macro ‘CHECK_TYPE_SIZE’ CHECK_TYPE_SIZE(__kernel_old_uid_t); ^ /home/pthaugen/src/gcc/trunk/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:247:72: error: size of array ‘assertion_failed__870’ is negative typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1] ^ /home/pthaugen/src/gcc/trunk/gcc/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:241:30: note: in expansion of macro ‘IMPL_COMPILER_ASSERT’ #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__) ^ /home/pthaugen/src/gcc/trunk/gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:739:3: note: in expansion of macro ‘COMPILER_CHECK’ COMPILER_CHECK(sizeof(__sanitizer_##TYPE) == sizeof(TYPE)) ^ /home/pthaugen/src/gcc/trunk/gcc/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:870:1: note: in expansion of macro ‘CHECK_TYPE_SIZE’ CHECK_TYPE_SIZE(__kernel_old_gid_t); ^ make: *** [sanitizer_platform_limits_posix.lo] Error 1
[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083 --- Comment #16 from Jeffrey A. Law --- Richi, No doubt about *0 = 1 and the like. While it's clearly undefined, I think we've got to continue to support catching the SIGSEGV/SIGBUS from a QOI standpoint. That's why I installed the changes to preserve the actual null dereferences yesterday. The cases where a NULL is passed as an argument to a function which declares the argument must be non-NULL isn't as clear cut. Similarly for a NULL which reaches a return statement in a function declared as returning non-NULL. I feel we're doing the right thing for those by just trapping. There's no guarantee the caller/callee will dereference those values -- all we know is a NULL pointer is disallowed in those cases by way of the attributes. And FWIW, we're going to have the same bundle of questions when we want to start isolating and trapping out of bounds array accesses. All cases look more and more like something we should be warning about. WRT non-call-exceptions on SJLJ targets, we should still have the EH edges around, so fixing the abnormal edge handing should be all we need to do (of course, SJLJ targets are less and less important, but presumably they're still around?)
[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #17 from Jeffrey A. Law ---
Markus,
For the kernel case, note the qsort prototype and the non-null attribute. That
explicitly states that the pointer arguments must not be null. Any code which
then passes null for those arguments has stepped into the realm of undefined
behaviour.
Prior to CCP2 we have:
main ()
{
int * _3;
;; basic block 2, loop depth 0, count 0, freq 1, maybe hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE)
;;pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE)
_3 = a.offset;
qsort (_3, 0);
return 0;
;;succ: EXIT [100.0%]
}
a.offset gets folded to zero by CCP2 resulting in:
main ()
{
;; basic block 2, loop depth 0, count 0, freq 1, maybe hot
;;prev block 0, next block 1, flags: (NEW, REACHABLE)
;;pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE)
qsort (0B, 0);
return 0;
;;succ: EXIT [100.0%]
}
Note we're passing NULL as the first argument to qsort, which has a declaration
saying that none of its pointer arguments can be NULL.
Note we're able to fold a.offset to zero because we can see "a"'s initializer.
AFAICT the code is doing exactly what is expected.
[Bug c++/59118] New: internal compiler error: Segmentation fault - with "using" keyword and template parameter(s) (C++11)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59118
Bug ID: 59118
Summary: internal compiler error: Segmentation fault - with
"using" keyword and template parameter(s) (C++11)
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reagentoo at gmail dot com
Minimal code where the bug is reproducible (http://ideone.com/tTVorC):
#include
template
class Test {
public:
template
using Wrapper = std::string;
template class C>
void func(const C& t) {
t;
return;
}
void test()
{
std::string sss;
Wrapper www;
func((const Wrapper&)sss);
}
};
int main(int argc, char *argv[])
{
Test ttt;
ttt.test();
}
[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083 --- Comment #18 from Markus Trippelsdorf --- (In reply to Jeffrey A. Law from comment #17) > For the kernel case, note the qsort prototype and the non-null attribute. > That explicitly states that the pointer arguments must not be null. Any > code which then passes null for those arguments has stepped into the realm > of undefined behaviour. Yes, I've already posted a patch to the LKML to fix this issue. Now the question is if one could also find *real* bugs with the help of -fisolate-erroneous-path and if the inconvenience of breaking otherwise "harmless" programs is counterbalanced by this ability?
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #9 from Peter Bergner --- I'm testing a fix for the left over failures.
[Bug c++/59083] -fisolate-erroneous-paths produces illegal instruction with enabled -fprofile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083 --- Comment #19 from Jeffrey A. Law --- Yes, the glibc guys have already found real bugs that they've fixed.
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #10 from Michael Meissner --- On Wed, Nov 13, 2013 at 06:03:50AM +, kcc at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 > > --- Comment #7 from Kostya Serebryany --- > Is this fixed by http://gcc.gnu.org/viewcvs?rev=204726&root=gcc&view=rev ? No, other patches are needed as communicated in the other threads on this.
[Bug middle-end/59119] New: Segfault in -fisolate-erroneous-paths pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59119
Bug ID: 59119
Summary: Segfault in -fisolate-erroneous-paths pass
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: uweigand at gcc dot gnu.org
Building the following test case (reduced from Python 2.7.5) with -O2 -g:
extern void *memmove (void *, const void *, __SIZE_TYPE__);
extern void *memset (void *, int, __SIZE_TYPE__);
typedef struct {
long n_prefix;
long n_spadding;
} NumberFieldWidths;
void
fill_number(char *buf, const NumberFieldWidths *spec)
{
if (spec->n_prefix) {
memmove(buf,
(char *) 0,
spec->n_prefix * sizeof(char));
buf += spec->n_prefix;
}
if (spec->n_spadding) {
memset(buf, 0, spec->n_spadding);
buf += spec->n_spadding;
}
}
crashes the compiler with:
formatter_string.i: In function ‘fill_number’:
formatter_string.i:11:1: internal compiler error: Segmentation fault
fill_number(char *buf, const NumberFieldWidths *spec)
^
0x1064f147 crash_signal
/home/uweigand/src/gcc/gcc/toplev.c:334
0x1090806c ptrofftype_p
/home/uweigand/src/gcc/gcc/tree.h:4463
0x1090806c build2_stat(tree_code, tree_node*, tree_node*, tree_node*)
/home/uweigand/src/gcc/gcc/tree.c:4151
0x1022c0db gimple_assign_rhs_to_tree(gimple_statement_d*)
/home/uweigand/src/gcc/gcc/cfgexpand.c:103
0x10861e67 insert_debug_temp_for_var_def(gimple_stmt_iterator_d*, tree_node*)
/home/uweigand/src/gcc/gcc/tree-ssa.c:442
0x10862397 insert_debug_temps_for_defs(gimple_stmt_iterator_d*)
/home/uweigand/src/gcc/gcc/tree-ssa.c:549
0x103ff49b gsi_remove(gimple_stmt_iterator_d*, bool)
/home/uweigand/src/gcc/gcc/gimple-iterator.c:563
0x10ba8083 insert_trap_and_remove_trailing_statements
/home/uweigand/src/gcc/gcc/gimple-ssa-isolate-paths.c:110
0x10ba8a47 gimple_ssa_isolate_erroneous_paths
/home/uweigand/src/gcc/gcc/gimple-ssa-isolate-paths.c:305
0x10ba8a47 execute
/home/uweigand/src/gcc/gcc/gimple-ssa-isolate-paths.c:370
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #11 from Peter Bergner --- This patch seem to have fixed the last of the powerpc64-linux build failures: Index: libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc === --- libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc (revision 204747) +++ libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc (working copy) @@ -855,6 +855,7 @@ CHECK_STRUCT_SIZE_AND_OFFSET(sigaction, CHECK_STRUCT_SIZE_AND_OFFSET(sigaction, sa_restorer); #endif +#ifdef SYSCALL_INTERCEPTION #if SANITIZER_LINUX CHECK_TYPE_SIZE(__sysctl_args); CHECK_SIZE_AND_OFFSET(__sysctl_args, name); @@ -872,6 +873,7 @@ CHECK_TYPE_SIZE(__kernel_off_t); CHECK_TYPE_SIZE(__kernel_loff_t); CHECK_TYPE_SIZE(__kernel_fd_set); #endif +#endif #if !SANITIZER_ANDROID CHECK_TYPE_SIZE(wordexp_t);
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #12 from Jakub Jelinek --- (In reply to Peter Bergner from comment #11) > This patch seem to have fixed the last of the powerpc64-linux build failures: > > Index: libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc > === > --- libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc > (revision 204747) > +++ libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc > (working copy) > @@ -855,6 +855,7 @@ CHECK_STRUCT_SIZE_AND_OFFSET(sigaction, > CHECK_STRUCT_SIZE_AND_OFFSET(sigaction, sa_restorer); > #endif > > +#ifdef SYSCALL_INTERCEPTION > #if SANITIZER_LINUX > CHECK_TYPE_SIZE(__sysctl_args); > CHECK_SIZE_AND_OFFSET(__sysctl_args, name); > @@ -872,6 +873,7 @@ CHECK_TYPE_SIZE(__kernel_off_t); > CHECK_TYPE_SIZE(__kernel_loff_t); > CHECK_TYPE_SIZE(__kernel_fd_set); > #endif > +#endif > > #if !SANITIZER_ANDROID > CHECK_TYPE_SIZE(wordexp_t); If it compiles/links and you don't get new undefined symbols from libasan, then I guess it should work (of course, please do make check to verify). If Kostya doesn't have anything against it and testing looks good, please write a ChangeLog and check it in.
[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009 --- Comment #13 from Kostya Serebryany --- No objections, thanks!
[Bug tree-optimization/59109] [4.9 regression] ICE in mark_reachable_handlers, at tree-eh.c:3826
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59109 Eric Botcazou changed: What|Removed |Added Target|ia64-*-*| Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-13 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- It's broken everywhere.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #13 from Jack Howarth --- (In reply to Alexander Potapenko from comment #12) > That was Foundation, not sure if CoreFoundation also works. Linking libasan against -Wl,-framework,CoreFoundation for gcc trunk at r204750 suppresses all of the failures in asan.exp on x86_64-apple-darwin12. Retesting with -Wl,-framework,Foundation.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #14 from Alexander Potapenko --- I think one of the frameworks depends on another one, please make sure to pick the latter one if that's true. Also add a comment denoting this is a dirty workaround. On Nov 13, 2013 9:38 PM, "howarth at nitro dot med.uc.edu" < gcc-bugzi...@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 > > --- Comment #13 from Jack Howarth --- > (In reply to Alexander Potapenko from comment #12) > > That was Foundation, not sure if CoreFoundation also works. > > Linking libasan against -Wl,-framework,CoreFoundation for gcc trunk at > r204750 > suppresses all of the failures in asan.exp on x86_64-apple-darwin12. > Retesting > with -Wl,-framework,Foundation. > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
[Bug rtl-optimization/59036] [4.9 regression] Performance degradation after r204212 on 32-bit x86 targets.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59036 --- Comment #3 from Vladimir Makarov --- Author: vmakarov Date: Wed Nov 13 18:00:43 2013 New Revision: 204752 URL: http://gcc.gnu.org/viewcvs?rev=204752&root=gcc&view=rev Log: 2013-11-13 Vladimir Makarov PR rtl-optimization/59036 * ira-color.c (struct allocno_color_data): Add new members first_thread_allocno, next_thread_allocno, thread_freq. (sorted_copies): New static var. (allocnos_conflict_by_live_ranges_p, copy_freq_compare_func): Move up. (allocno_thread_conflict_p, merge_threads) (form_threads_from_copies, form_threads_from_bucket) (form_threads_from_colorable_allocno, init_allocno_threads): New functions. (bucket_allocno_compare_func): Add comparison by thread frequency and threads. (add_allocno_to_ordered_bucket): Rename to add_allocno_to_ordered_colorable_bucket. Remove parameter. (push_only_colorable): Call form_threads_from_bucket. (color_pass): Call init_allocno_threads. Use consideration_allocno_bitmap instead of coloring_allocno_bitmap for nuillify allocno color data. (ira_initiate_assign, ira_finish_assign): Allocate/free sorted_copies. (coalesce_allocnos): Use static sorted copies. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-color.c
[Bug middle-end/59119] Segfault in -fisolate-erroneous-paths pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59119 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-11-13 CC||law at redhat dot com Assignee|unassigned at gcc dot gnu.org |law at redhat dot com Ever confirmed|0 |1 --- Comment #1 from Jeffrey A. Law --- Thanks Ulrich. I'm pretty sure I know what's going on here. When we remove statements after the builtin_trap, we remove them in statement order: ;; basic block 3, loop depth 0 ;;pred: 2 _8 = (long unsigned int) _6; memmove (buf_7(D), 0B, _8); _10 = spec_5(D)->n_prefix; _11 = (sizetype) _10; buf_12 = buf_7(D) + _11; # DEBUG buf => buf_12 In this block we're going to insert a __builtin_trap before the memmove call as memmove is not allowed to have NULL pointer arguments. When then proceed to remove the remaining statements in the block starting with the memmove call proceeding to the end of the block. As we remove statements with an LHS (such as _11 = ...) we release the SSA name back to the name manager. The problem is once released, we're not supposed to touch the names anymore. But a later remove (say of the statement buf_12 = ... ) may try to insert debug temps which will look at the RHS of that statement. In particular it'll look at SSA_NAME 11 which we have already released to the manager. This should be an easy fix.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #15 from Jack Howarth --- (In reply to Alexander Potapenko from comment #14) > I think one of the frameworks depends on another one, please make sure to > pick the latter one if that's true. > Also add a comment denoting this is a dirty workaround. > On Nov 13, 2013 9:38 PM, "howarth at nitro dot med.uc.edu" < > gcc-bugzi...@gcc.gnu.org> wrote: > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 > > > > --- Comment #13 from Jack Howarth --- > > (In reply to Alexander Potapenko from comment #12) > > > That was Foundation, not sure if CoreFoundation also works. > > > > Linking libasan against -Wl,-framework,CoreFoundation for gcc trunk at > > r204750 > > suppresses all of the failures in asan.exp on x86_64-apple-darwin12. > > Retesting > > with -Wl,-framework,Foundation. > > > > -- > > You are receiving this mail because: > > You are on the CC list for the bug. > > The Foundation framework is already linked against the CoreFoundation framework. I've confirmed that linking libasan against -Wl,-framework,Foundation alone (as is done by llvm) is sufficient to suppress the asan.exp failures. This change will duplicate the linkage used by llvm for the asan shared library. Posted proposed patch at http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01499.html,
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #16 from Alexander Potapenko --- I've actually removed the Foundation linkage from LLVM today. On Nov 13, 2013 10:45 PM, "howarth at nitro dot med.uc.edu" < gcc-bugzi...@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 > > --- Comment #15 from Jack Howarth --- > (In reply to Alexander Potapenko from comment #14) > > I think one of the frameworks depends on another one, please make sure to > > pick the latter one if that's true. > > Also add a comment denoting this is a dirty workaround. > > On Nov 13, 2013 9:38 PM, "howarth at nitro dot med.uc.edu" < > > gcc-bugzi...@gcc.gnu.org> wrote: > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 > > > > > > --- Comment #13 from Jack Howarth > --- > > > (In reply to Alexander Potapenko from comment #12) > > > > That was Foundation, not sure if CoreFoundation also works. > > > > > > Linking libasan against -Wl,-framework,CoreFoundation for gcc trunk at > > > r204750 > > > suppresses all of the failures in asan.exp on x86_64-apple-darwin12. > > > Retesting > > > with -Wl,-framework,Foundation. > > > > > > -- > > > You are receiving this mail because: > > > You are on the CC list for the bug. > > > > > The Foundation framework is already linked against the CoreFoundation > framework. I've confirmed that linking libasan against > -Wl,-framework,Foundation alone (as is done by llvm) is sufficient to > suppress > the asan.exp failures. This change will duplicate the linkage used by llvm > for > the asan shared library. Posted proposed patch at > http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01499.html, > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
[Bug middle-end/59119] Segfault in -fisolate-erroneous-paths pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59119 --- Comment #2 from Jeffrey A. Law --- Ah nuts. While pondering this a bit more, I realized we have the same problem in this code that we do in DOM. Namely that we can have references to SSA_NAMEs that have been released to the name manager in blocks that become unreachable. That's fine except that we're also creating new SSA_NAMEs which is strictly verboten if there are still references to released names in the IL. I'm going to have to ponder this a bit more.
[Bug ada/54040] [x32] Incorrect timeval and timespec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54040 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-13 Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01504.html
[Bug ada/54040] [x32] Incorrect timeval and timespec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54040 H.J. Lu changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #2 from H.J. Lu --- Without the fix, many Ada tests fail with timeout: FAIL: gnat.dg/curr_task.adb execution test FAIL: gnat.dg/interface2.adb execution test FAIL: gnat.dg/lto8.adb execution test FAIL: gnat.dg/null_pointer_deref2.adb execution test FAIL: gnat.dg/requeue1.adb execution test FAIL: gnat.dg/stack_check1.adb execution test FAIL: gnat.dg/stack_check2.adb execution test FAIL: gnat.dg/task_stack_align.adb execution test FAIL: gnat.dg/test_image.adb execution test FAIL: gnat.dg/test_prio.adb execution test FAIL: gnat.dg/timer_cancel.adb execution test
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #17 from Jack Howarth --- (In reply to Alexander Potapenko from comment #16) > I've actually removed the Foundation linkage from LLVM today. Unfortunately, that is impossible to test here. A remerge of llvm libsanitizer at 194597 with gcc trunk at r204752 bootstraps on x86_64-apple-darwin12 but shows lots of new test suite failures in asan.exp... FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test, is dyld: Symbol not found: __ZN11__sanitizer10Symbolizer21symbolizer_allocator_E Referenced from: /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libsanitizer/asan/.libs/libasan.1.dylib Expected in: flat namespace in /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libsanitizer/asan/.libs/libasan.1.dylib , should match READ of size 1 at 0x[0-9a-f]+ thread T0.*( | )#0 0x[0-9a-f]+ (in _*main ([^ ]*global-overflow-1.c:20|[^ ]*:0)|[(])[^ ]*( | ).*0x[0-9a-f]+ is located 0 bytes to the right of global variable.*YYY[^ ]* of size 10[^ ]*( | ) Shouldn't llvm's libsanitizer be better synced with FSF gcc's at this point?
[Bug target/57363] IBM long double: adding NaN and number raises inexact exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57363 Ulrich Weigand changed: What|Removed |Added CC||uweigand at gcc dot gnu.org --- Comment #3 from Ulrich Weigand --- Hi Adhemerval, I'm also seeing that this patch fixes some glibc failures. What's the status of this? Were you planning to submit it for inclusion? B.t.w. I'm wondering if we don't need to use + if (fabs (z) != inf()) + return z; instead; z could still be minus infinity, right?
[Bug c++/59056] enable_if turns a non-ambiguous template into an ambiguous one
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056 --- Comment #5 from Richard Smith --- (In reply to Jonathan Wakely from comment #2) > I thought if the partial specializations were ambiguous then these function > overloads should be too. Yes, this inconsistency is very surprising. GCC, EDG, and Clang all behave the same way, and yet I can find no justification for this behavior in the standard. Morally, the function call should be ambiguous. The first 'func' takes Bar for any X where check() is true, and the second 'func' takes Bar for any X that matches Foo. Neither of those constraints implies the other, so the call should be ambiguous. In Clang's case, the problem is that we fail to enforce [temp.deduct.type](14.8.2.5)/1 when partially ordering function templates -- we don't check that deduction actually succeeded in finding types that make 'A' match the 'deduced A' -- but we do check that when partially ordering class templates, and we don't spot the problem earlier because the enable_if<...> is a non-deduced context. I expect EDG and GCC have a similar bug.
[Bug c++/59120] [c++11] ICE with invalid template alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59120 Volker Reichelt changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code Priority|P3 |P5 Known to fail||4.7.0, 4.8.0, 4.9.0
[Bug c++/59120] New: [c++11] ICE with invalid template alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59120 Bug ID: 59120 Summary: [c++11] ICE with invalid template alias Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: reichelt at gcc dot gnu.org The following invalid line of code (compiled with "-std=c++11") triggers an ICE since GCC 4.7.0 (when template alias was introduced): = template using X = int T::T*; = bug.cc:1:36: error: expected ';' template using X = int T::T*; ^ bug.cc:1:39: internal compiler error: in dependent_type_p, at cp/pt.c:20192 template using X = int T::T*; ^ 0x596ea0 dependent_type_p(tree_node*) ../../gcc/gcc/cp/pt.c:20192 0x597644 dependent_scope_p(tree_node*) ../../gcc/gcc/cp/pt.c:20223 0x639251 cp_parser_lookup_name ../../gcc/gcc/cp/parser.c:21789 0x658ec0 cp_parser_class_name ../../gcc/gcc/cp/parser.c:18819 0x65935c cp_parser_constructor_declarator_p ../../gcc/gcc/cp/parser.c:4 0x65935c cp_parser_decl_specifier_seq ../../gcc/gcc/cp/parser.c:11374 0x65fd89 cp_parser_simple_declaration ../../gcc/gcc/cp/parser.c:10979 0x643860 cp_parser_block_declaration ../../gcc/gcc/cp/parser.c:10928 0x66aaae cp_parser_declaration ../../gcc/gcc/cp/parser.c:10825 0x6697ca cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:10711 0x66b0e6 cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:3989 0x66b0e6 c_parse_file() ../../gcc/gcc/cp/parser.c:30962 0x787f73 c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1046 Please submit a full bug report, [etc.]
[Bug tree-optimization/59121] New: endless loop with -O2 -floop-parallelize-all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121 Bug ID: 59121 Summary: endless loop with -O2 -floop-parallelize-all Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: janus at gcc dot gnu.org Consider the following simple Fortran code: subroutine smooth1 implicit none integer :: j, k, l, nbin1(3) real, dimension(55,48,49) :: atemp, acc common /ACC_INPUT/ nbin1 do j=1,nbin1(1) do k=1,nbin1(2) do l=1,nbin1(3) acc(j,k,l) = atemp(j,k,l) end do end do end do end Compiling this with "gfortran -c -O2 -floop-parallelize-all" apparently never finishes. $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran 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/Linaro 4.8.1-10ubuntu8' --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 --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.1 (Ubuntu/Linaro 4.8.1-10ubuntu8)
[Bug tree-optimization/59102] [4.9 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59102 Jeffrey A. Law changed: What|Removed |Added Status|NEW |ASSIGNED CC||law at redhat dot com Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #2 from Jeffrey A. Law --- No, it should be checking is_gimple_assign before looking at the . We don't want to allow a case where there's a call on the RHS as that call may have observable side effects that would get wiped out.
[Bug ipa/58862] [4.9 Regression] LTO profiledbootstrap failure: lto1: ICE in edge_badness, at ipa-inline.c:1008
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862 --- Comment #24 from tejohnson at gcc dot gnu.org --- Author: tejohnson Date: Wed Nov 13 21:48:59 2013 New Revision: 204755 URL: http://gcc.gnu.org/viewcvs?rev=204755&root=gcc&view=rev Log: 2013-11-13 Teresa Johnson PR ipa/58862 * ipa-inline.c (edge_badness): Fix overflow. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c
[Bug ipa/58862] [4.9 Regression] LTO profiledbootstrap failure: lto1: ICE in edge_badness, at ipa-inline.c:1008
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862 --- Comment #25 from tejohnson at gcc dot gnu.org --- Author: tejohnson Date: Wed Nov 13 21:51:44 2013 New Revision: 204756 URL: http://gcc.gnu.org/viewcvs?rev=204756&root=gcc&view=rev Log: 2013-11-13 Teresa Johnson PR ipa/58862 * predict.c (drop_profile): Error is currently too strict. (handle_missing_profiles): Pass call_count to drop_profile. Modified: trunk/gcc/ChangeLog trunk/gcc/predict.c
