[Bug testsuite/63305] New: ASan reported heap-buffer-overflow in gcc.target/i386/avx256-unaligned-load{store}-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63305
Bug ID: 63305
Summary: ASan reported heap-buffer-overflow in
gcc.target/i386/avx256-unaligned-load{store}-7.c
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: chefmax at gcc dot gnu.org
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build: x86_64-pc-linux-gnu
ASan reported heap-buffer-overflow in
gcc.target/i386/avx256-unaligned-load{store}-7.c:
$ ~/master/gcc gcc/testsuite/gcc.target/i386/avx256-unaligned-load-7.c
-fsanitize=address -O3 -dp -mavx -mavx256-split-unaligned-load -o
./avx256-unaligned-load-7.exe
$ ./avx256-unaligned-load-7.exe
=
==21855==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60c0c000 at pc 0x400bcc bp 0x7fffd03d3d90 sp 0x7fffd03d3d88
WRITE of size 8 at 0x60c0c000 thread T0
#0 0x400bcb in do_test
(/home/max/build/master-x86_64/avx256-unaligned-load-7.exe+0x400bcb)
#1 0x40086f in main
(/home/max/build/master-x86_64/avx256-unaligned-load-7.exe+0x40086f)
#2 0x7fecbc89476c in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2176c)
#3 0x4008c4
(/home/max/build/master-x86_64/avx256-unaligned-load-7.exe+0x4008c4)
0x60c0c000 is located 0 bytes to the right of 128-byte region
[0x60c0bf80,0x60c0c000)
allocated by thread T0 here:
#0 0x7fecbccc5569 in __interceptor_malloc
/home/max/workspace/downloads/gcc/libsanitizer/asan/asan_malloc_linux.cc:73
#1 0x4009bd in foo
(/home/max/build/master-x86_64/avx256-unaligned-load-7.exe+0x4009bd)
SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 do_test
Shadow bytes around the buggy address:
0x0c187fff97b0: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
0x0c187fff97c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c187fff97d0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
0x0c187fff97e0: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
0x0c187fff97f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=0x0c187fff9800:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c187fff9810: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c187fff9820: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c187fff9830: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c187fff9840: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c187fff9850: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Container overflow: fc
ASan internal: fe
==21855==ABORTING
Quick analysis shows that overflow happens at line 38. Perhaps allocated arrays
have wrong size.
[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Your testcase is definitely not valid C, you can't perform pointer arithmetics in between pointers that don't point into the same array or one past the last element in the array.
[Bug target/63304] Aarch64 pc-relative load offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||aarch64 Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-19 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Confirmed. From .expand: (insn 5 4 6 (set (reg:DF 75) (mem/u/c:DF (symbol_ref/u:DI (*.LC0) [flags 0x2]) [0 S8 A64])) /home/pinskia/Downloads/x.c:7 -1 (nil)) Note next time please use macros to create your testcase, it is ok sometimes to use non preprocessed source
[Bug c++/63306] New: [4.9 Regression] ICE: Segmentation fault in analyze_functions()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63306
Bug ID: 63306
Summary: [4.9 Regression] ICE: Segmentation fault in
analyze_functions()
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
markus@x4 tmp % cat context.ii
template typename...
class A;
class B {
B(const int , const Aint, int );
};
B::B(const int , const Aint, int ) {}
markus@x4 tmp % g++ -std=c++11 -c context.ii
cc1plus: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
This is the issue from PR63244 comment 4.
[Bug c++/63306] [4.9 Regression] ICE: Segmentation fault in analyze_functions()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63306 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2014-9-19 Target Milestone|--- |4.9.2 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Started with r202298.
[Bug middle-end/63244] [4.9 regression] internal compiler error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63244 --- Comment #11 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #10) The testcase from comment 4 started segfaulting with r202298. I've opened PR63306 for this issue.
[Bug c/63301] inconsistency on wchar_t and wint_t types and sizes for diverse architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63301 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- %lc requires an argument of type wint_t, so the warning is correct.
[Bug fortran/63294] ICE allocattion of array of type of type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63294 --- Comment #2 from Valery Weber valeryweber at hotmail dot com --- the problem is the same as 61952
[Bug fortran/63294] ICE allocattion of array of type of type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63294 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- the problem is the same as 61952 So, marked as duplicate of pr61952. Why did you open an new empty PR? *** This bug has been marked as a duplicate of bug 61952 ***
[Bug fortran/61952] ICE allocattion of array of type of type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61952 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 63294 has been marked as a duplicate of this bug. ***
[Bug target/62662] [4.9/5 Regression] Miscompilation of Qt on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62662 --- Comment #7 from Andreas Krebbel krebbel at gcc dot gnu.org --- Author: krebbel Date: Fri Sep 19 09:14:59 2014 New Revision: 215381 URL: https://gcc.gnu.org/viewcvs?rev=215381root=gccview=rev Log: 2014-09-19 Andreas Krebbel andreas.kreb...@de.ibm.com PR target/62662 * config/s390/s390.c (s390_emit_epilogue): When doing the return address load optimization force s390_optimize_prologue to leave it that way. Only do the optimization if we already decided to push r14 into a stack slot. Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.c
[Bug c++/60420] [C++11] Bogus error: ‘const’ qualifiers cannot be applied to ‘int’ with lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60420
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-09-19
Ever confirmed|0 |1
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com ---
In mainline we don't ICE anymore. This is enough to reproduce the issue:
struct Iterator
{
int operator*();
};
void foo(Iterator begin)
{
auto x = [](const decltype(*begin)) { };
}
Note, anyway, that the EDG front-end warns.
[Bug target/62662] [4.9/5 Regression] Miscompilation of Qt on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62662 --- Comment #8 from Andreas Krebbel krebbel at gcc dot gnu.org --- Author: krebbel Date: Fri Sep 19 09:20:38 2014 New Revision: 215383 URL: https://gcc.gnu.org/viewcvs?rev=215383root=gccview=rev Log: 2014-09-19 Andreas Krebbel andreas.kreb...@de.ibm.com PR target/62662 * config/s390/s390.c (s390_emit_epilogue): When doing the return address load optimization force s390_optimize_prologue to leave it that way. Only do the optimization if we already decided to push r14 into a stack slot. Modified: branches/gcc-4_9-branch/gcc/config/s390/s390.c
[Bug c++/58328] [C++11] bogus: error: constructor required before non-static data member for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58328 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Thus, I'm going to add to the testsuite both testcases as ill-formed and closing the bug.
[Bug middle-end/63186] [4.9/5 Regression] Undefined .L* symbols because of fnsplit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63186 --- Comment #5 from Dan Horák dan at danny dot cz --- Jan, can you backport the fix also to 4.9? It is causing a problem in Fedora where at least one build is failing due this problem.
[Bug c++/58328] [C++11] bogus: error: constructor required before non-static data member for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58328 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug c++/58328] [C++11] bogus: error: constructor required before non-static data member for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58328 --- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Fri Sep 19 09:34:14 2014 New Revision: 215386 URL: https://gcc.gnu.org/viewcvs?rev=215386root=gccview=rev Log: 2014-09-19 Paolo Carlini paolo.carl...@oracle.com PR c++/58328 * g++.dg/cpp0x/nsdmi10.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi10.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/61951] -Wextra switch produce warning: parameter 'ptr' set but not used [-Wunused-but-set-parameter]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61951 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks Jakub. Now that I notice that specific line and you confirmed that the warning is intentional in the non-lambda case, I believe we can close the bug.
[Bug c/63307] New: [4.9/5 Regression] Cilk+ breaks -fcompare-debug bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63307 Bug ID: 63307 Summary: [4.9/5 Regression] Cilk+ breaks -fcompare-debug bootstrap Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org CC: izamyatin at gmail dot com, kyukhin at gcc dot gnu.org I've just tried a -fcompare-debug bootstrap, and one of the two reasons (other was Ada) that it failed is Cilk+: ../configure --enable-languages=all,ada,obj-c++,lto,go --enable-checking=release; GCC_COMPARE_DEBUG=1 make -j48 bootstrap LOG 21 GCC_COMPARE_DEBUG=1 make -j48 -k check LOGC 21; ../contrib/test_summary LOGT 21 ... xg++: error: ../../../libcilkrts/runtime/cilk-abi-cilk-for.cpp: -fcompare-debug failure (length) From what I can see, the bug is (at least) in c-family/cilk.c, where it seems in all 4 traverse handlers on decl_map it creates decls, adds fields etc. That is a big NO NO in GCC, hash table traversal order should never affect code generation. So, seeing changes like: - _cilk_spn_1 (low, grain, mid, body, loop_root_pedigree, data, w); + _cilk_spn_1 (data, body, loop_root_pedigree, w, mid, low, grain); or: -built-in (unsigned int D.3190, int D.3189, unsigned int D.3188, void (*T39b) (void *, unsigned int, unsigned int) D.3187, struct __cilkrts_pedigree * D.3186, void * D.3185, struct __cilkrts_worker * D.3184) +built-in (void * D.3190, void (*T39b) (void *, unsigned int, unsigned int) D.3189, struct __cilkrts_pedigree * D.3188, struct __cilkrts_worker * D.3187, unsigned int D.3186, unsigned int D.3185, int D.3184) in *.gimple dump between -g and -g0 is just wrong (and in this case it isn't really debug related, just different order in the hash map). If you don't have the decls (but, apparently you put also BLOCKs in there, what else?) you want to traverse in some other data structure, you can e.g. traverse the hash table but only collect the decls (do you need anything else, e.g. the BLOCKs?, types, etc.) you saw into some vector, then qsort the vector (for decls e.g. by DECL_UID, if you have also other trees, it might be harder) and then traverse the sorted vector insert of traversing random order hash map.
[Bug c++/63295] Insane memory use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63295 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||memory-hog Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-19 Ever confirmed|0 |1
[Bug c++/63308] New: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63308 Bug ID: 63308 Summary: internal compiler error: Segmentation fault Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mnsc at dtu dot dk
[Bug target/63304] Aarch64 pc-relative load offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org --- I see this as a theoretical problem that's unlikely to ever manifest itself with real code (functions generating .5 million instructions would take insanely long to compile in real life). Unless you can show some *real* code that exhibits this problem I propose we don't try to fix this; it's just a limit on the compiler. We have bigger problems to worry about.
[Bug c++/63308] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63308 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-09-19 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Please provide the info requested by https://gcc.gnu.org/bugs/
[Bug c++/63309] New: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63309 Bug ID: 63309 Summary: internal compiler error: Segmentation fault Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mnsc at dtu dot dk Created attachment 33516 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33516action=edit Minimal example I get internal compiler error: Segmentation fault (no proper error message) when compiling the attached minimal example.
[Bug fortran/63152] needless initialization of local pointer arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63152 --- Comment #3 from vondele at gcc dot gnu.org --- Author: vondele Date: Fri Sep 19 10:28:00 2014 New Revision: 215387 URL: https://gcc.gnu.org/viewcvs?rev=215387root=gccview=rev Log: 2014-09-19 Joost VandeVondele vond...@gcc.gnu.org PR fortran/63152 * trans-array.c (gfc_trans_deferred_array): Only nullify allocatables. 2014-09-19 Joost VandeVondele vond...@gcc.gnu.org PR fortran/63152 * gfortran.dg/auto_char_dummy_array_1.f90: Fix undefined behavior. * gfortran.dg/pr63152.f90: New test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/auto_char_dummy_array_1.f90
[Bug fortran/63152] needless initialization of local pointer arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63152 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- fixed.
[Bug libstdc++/60421] std::this_thread::sleep_for doesn't sleep for all arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60421 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-19 Target Milestone|--- |5.0 Ever confirmed|0 |1
[Bug libstdc++/31247] std::vector::iterator::value_type is accessible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247 --- Comment #15 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Marc Glisse from comment #10) that's exactly what you'll test, since iterator_traits is not guaranteed to be sfinae-friendly. N.B. that's changed for C++14. I'm still not motivated to implement this request though.
[Bug libstdc++/48101] obscure error message with std::setconst int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48101 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-19 Ever confirmed|0 |1 Severity|normal |enhancement
[Bug libstdc++/51008] GTHR - extend interface with __gthread_recursive_mutex_destroy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51008 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.0 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Andrey Galkin from comment #0) I can propose two solutions: 1. Add __gthread_recursive_mutex_destroy and get rid of _S_destroy template hacks. That was done for GCC 4.8, see PR 53889, so this should be fixed.
[Bug libstdc++/51618] synchronous futures are slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51618 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/62046] A catch in a class, without any try, compiles fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62046
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com ---
I think it can be reduced like this:
void foo() { } catch (...);
class bar { void foo() { } catch (...); };
we reject only the former.
[Bug libstdc++/53626] [C++11] move assignment for ifstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53626 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-09-19 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1
[Bug libstdc++/56437] basic_string assumes that allocators are default-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56437 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-09-19 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1
[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-09-19 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1
[Bug libstdc++/57953] no C++11 compliant std::ios_base::failure found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57953 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-19 Target Milestone|--- |5.0 Ever confirmed|0 |1
[Bug libstdc++/55394] Using call_once without -lpthread compiles without warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55394 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- related to PR 58929
[Bug libstdc++/58929] condition_variable does not wait without -pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58929 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- related to PR 55394
[Bug target/60624] creation of working linux sparc32 kernel fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60624 Waldemar Brodkorb wbx at openadk dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from Waldemar Brodkorb wbx at openadk dot org --- Fixed by following kernel change: http://patchwork.ozlabs.org/patch/384285/
[Bug libstdc++/59192] error: use of deleted function ‘A::A(const A)’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59192 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- GCC's std::deque now meets the C++11 allocator requirements, but still doesn't have a noexcept move constructor so the example in this PR still doesn't compile (which is conforming behaviour, the standard says the example is invalid).
[Bug libstdc++/59987] [C++11]: Missing ios_base::hexfloat format specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59987 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-09-19 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- There's a patch for this waiting to be applied.
[Bug libstdc++/60176] [C++11] void return value in std::list::insert() c++1 should be an iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60176 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|unknown |4.8.2 Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- This was fixed for 4.9.0
[Bug libstdc++/60278] string::erase() (and other containers) does not take const_iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60278 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-09-19 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1
[Bug libstdc++/60396] Missing time_get::get() functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60396 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-19 Target Milestone|--- |5.0 Ever confirmed|0 |1
[Bug libstdc++/60333] type_traits make_signed, make_unsigned missing support for long long enumerations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60333 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-19 Ever confirmed|0 |1
[Bug c++/63309] [4.8/4.9/5 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63309 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-19 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |4.8.4 Summary|internal compiler error:|[4.8/4.9/5 Regression] |Segmentation fault |internal compiler error: ||Segmentation fault Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- ICE started with r189298, before that it has been rejected: pr63309.C:9:13: error: invalid class name in declaration of ‘class AT::B’ class AT::B ^ pr63309.C: In function ‘int main()’: pr63309.C:16:15: error: aggregate ‘Aint::B myB’ has incomplete type and cannot be defined Aint::B myB; ^
[Bug c++/63309] [4.8/4.9/5 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63309 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 63308 has been marked as a duplicate of this bug. ***
[Bug c++/63308] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63308 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- *** This bug has been marked as a duplicate of bug 63309 ***
[Bug libstdc++/31247] std::vector::iterator::value_type is accessible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247 --- Comment #16 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #15) I'm still not motivated to implement this request though. It would break too much code. If people really insisted (which they don't), I believe it would be safer to specialize iterator_traits and _remove_ the nested vector::iterator::* typedefs than to make them private, since access control in C++ is a trap.
[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58192 --- Comment #8 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Jakub Jelinek from comment #7) That is to be determined. Either it might be an x86_64 bug in passing such types, or FE issue, middle-end. Please note that the error also occurs with -m32, so it seems highly unlikely an x86_64 target-dependent bug.
[Bug ada/63310] New: Ada bootstrap error with -fcompare-debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63310 Bug ID: 63310 Summary: Ada bootstrap error with -fcompare-debug Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org CC: charlet at gcc dot gnu.org, ebotcazou at gcc dot gnu.org My: ../configure --enable-languages=all,ada,obj-c++,lto,go --enable-checking=release; GCC_COMPARE_DEBUG=1 make -j48 bootstrap LOG 21 GCC_COMPARE_DEBUG=1 make -j48 -k check LOGC 21; ../contrib/test_summary LOGT 21 bootstrap on x86_64 failed with: xgcc: error: a-rttiev.adb: -fcompare-debug failure It seems this is caused by gnat_write_global_declarations, which creates dummy_global decl AND corresponding varpool node for it (the former is not a problem I think, we only require that decls that are created for both -g and -g0 sort by DECL_UIDs the same (i.e. -g can have bigger gaps in the uids than -g0), but for cgraph nodes e.g. node-order is visible in the dumps), and for -g0 used_types_insert doesn't emit anything into types_used_by_cur_var_decl vector, while for -g if there are global vars it sometimes does. I have no idea what is dummy_global good for, but if you need it, it probably has to be created regardless of whether types_used_by_cur_var_decl vector is empty or not.
[Bug ada/63310] Ada bootstrap error with -fcompare-debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63310 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.2
[Bug libstdc++/54354] TODO extended iomanip manipulators std::get_time and std::put_time (C++11, section 27.7.5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54354 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58192
--- Comment #9 from Uroš Bizjak ubizjak at gmail dot com ---
Looking at dumps, obtained with -m32 -O1, we have following sequence before the
call to _ZN2S1Ut_3setE3Foo:
_.dfinit:
(insn 7 3 8 2 (parallel [
(set (reg:SI 88)
(lshiftrt:SI (reg/v:SI 86 [ t ])
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
]) 539 {*lshrsi3_1}
(nil))
(insn 8 7 9 2 (parallel [
(set (reg:QI 85 [ t$2 ])
(and:QI (subreg:QI (reg:SI 88) 0)
(const_int -1 [0x])))
(clobber (reg:CC 17 flags))
]) 379 {*andqi_1}
(nil))
...
(insn 10 9 11 2 (set (reg:QI 1 dx)
(reg:QI 85 [ t$2 ])) gcc-bug.cc:72 93 {*movqi_internal}
(nil))
...
(call_insn 12 11 13 2 (call (mem:QI (symbol_ref:SI (_ZN2S1Ut_3setE3Foo)
[flags 0x3] function_decl 0x2ad94c491438 set) [0 set S1 A8])
(const_int 0 [0])) gcc-bug.cc:72 651 {*call}
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil))
(expr_list:SI (use (reg:SI 0 ax))
(expr_list:QI (use (reg:QI 1 dx))
(nil
_.cse1 mangles argument setup to:
(insn 8 7 9 2 (set (reg:QI 85 [ t$2 ])
(subreg:QI (reg:SI 88) 0)) 93 {*movqi_internal}
(expr_list:REG_DEAD (reg:SI 88)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
...
(insn 10 9 11 2 (set (reg:QI 1 dx)
(subreg:QI (reg:SI 88) 0)) gcc-bug.cc:72 93 {*movqi_internal}
(nil))
and _.fwprop1 merges both to:
(insn 10 9 11 2 (set (reg:QI 1 dx)
(subreg:QI (reg:SI 88) 0)) gcc-bug.cc:72 93 {*movqi_internal}
(nil))
resulting in:
#(insn 10 9 34 2 (set (reg:QI 1 dx)
#(reg:QI 3 bx [88])) gcc-bug.cc:72 93 {*movqi_internal}
# (nil))
movl%ebx, %edx# 10*movqi_internal/1[length = 2]
However, x86 ABI mandates that arguments should be properly extended in the
call to the function. I don't think original (insn 8) is correct, as it is
effectively a NOP.
[Bug c/63301] inconsistency on wchar_t and wint_t types and sizes for diverse architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63301 --- Comment #2 from Marcos Diaz marcos.diaz at tallertechnologies dot com --- Sorry, I expressed wrong the issue I was reporting, What I want to ask is the following: Is it ok that the wchar_t is a long int and the wint_t is just an int?
[Bug libstdc++/58266] gcc-4.7.3: memleaks reported by valgrind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58266 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- I doubt this is a bug in libstdc++. It's only a possibly lost report, but even if there's a real problem it's more likely to be in matplotlib. Please reopen if you have code to reproduce the problem, otherwise this is too vague to do anything about.
[Bug libstdc++/60662] simple use of call_once throws a system_error exception, but not if sleep_for is called beforehand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60662 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- Probably related to PR 55394
[Bug libstdc++/61041] Cannot create std::tr1::variate_generator from variate_generator::engine(); engine_value_type error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61041 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- TR1 is moribund
[Bug libstdc++/61426] [C++11] std::deque requires more from allocator than the standard provides.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61426 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed on trunk.
[Bug libstdc++/62169] map iterators under _GLIBCXX_DEBUG diverge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62169 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- The cure would be worse than the disease.
[Bug fortran/44882] Bogus types in references with mismatched commons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44882 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |WAITING --- Comment #14 from Dominique d'Humieres dominiq at lps dot ens.fr --- I dont see any ICE for the test in comment 12 on powerpc-apple-darwin9 (from 4.4.7 to r214282). Any reason why this PR is still open?
[Bug libstdc++/54392] [4.8/4.9/5 Regression] std::string::assign() fails to update length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Blocks||24882 Target Milestone|4.8.4 |5.0
[Bug libstdc++/53221] [C++11] basic_string lacks copy/move constructors with allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53221 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Blocks||24882 Target Milestone|--- |5.0
[Bug libstdc++/61458] std::aligned_storage is bigger than expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61458 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-19 Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- If we're going to fix this we should do it now, before the C++11 ABI is declared stable.
[Bug rtl-optimization/58968] Powerpc -mlra cannot compile ormas1.f in gamess Spec 2006 with -m32 -mcpu=power7 -O3 -mlra -w -ffast-math -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58968 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Is this PR fixed or not?
[Bug c/53874] -Wswitch-enum not properly working with bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53874 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Patch I've just posted should fix this as well.
[Bug libstdc++/55963] std::vectorconst T fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55963 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- Same issue *** This bug has been marked as a duplicate of bug 48101 ***
[Bug libstdc++/48101] obscure error message with std::setconst int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48101 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||corey at octayn dot net --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 55963 has been marked as a duplicate of this bug. ***
[Bug target/56993] power gcc built 416.gamess generates wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-09-19 Ever confirmed|0 |1 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr --- This has already been discussed for gfortran in PR44882 and PR53086 and seems related to PR53265.
[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303 --- Comment #2 from mikulas at artax dot karlin.mff.cuni.cz --- Jakub Jelinek: I know, but the problem happened in perfectly valid program. Suppose that you do: char *p = malloc(0x2000); - the allocator allocates the array at 0x7000. Then, you do: char *q = p + 0x2000; /* q is 0x9000, pointing to the end of the array */ long n = q - p; --- this triggers the warning, although it is perfectly valid operation. The above case is non-reproducible because it depends on the address returned from the allocator. I wrote the example code to trigger the warning deterministically.
[Bug c++/63306] [4.9 Regression] ICE: Segmentation fault in analyze_functions()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63306 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED CC||hubicka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- Mine, does not reproduce on mainline for me.
[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
||jsm28 at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
The problem is that we don't have a POINTER_DIFF_EXPR similar to
POINTER_PLUS_EXPR, which would take two pointers and return an integer, and the
FEs emit pointer difference as cast of both the pointers to signed integral
type
and subtracts the integers.
If
ssize_t foo (char *p, char *q) { return p - q; }
is changed into
ssize_t foo (char *p, char *q) { return (ssize_t) p - (ssize_t) q; }
by the FE, then indeed if you have array starting at 0x7fff and ending at
0x8001 and subtract those two pointers, you get undefined behavior.
That is undefined behavior not just for ubsan, but for anything else in the
middle-end.
So, if pointer difference is supposed to behave differently, then
we'd either need to represent pointer difference as
ssize_t foo (char *p, char *q) { return (ssize_t) ((size_t) p - (size_t) q); }
(but we risk missed optimizations that way I'd say), or we'd need a better
representation of it in the middle-end.
[Bug libstdc++/60940] general operations on atomic types do not work with atomic integral typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60940 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug libstdc++/60555] std::system_category().default_error_condition() doesn't map system errno values to std::generic_category()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60555 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug c++/62219] [c++11] Spurious error for lambda in a friend function of a class template with a default template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62219 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- I think I had in mind c++/60605
[Bug target/63304] Aarch64 pc-relative load offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304 --- Comment #5 from Venkataramanan venkataramanan.kumar at amd dot com --- We got inspired by this bug. https://bugs.linaro.org/show_bug.cgi?id=400 It happens at -O0 now.
[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58192
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org ---
When I compile:
#ifdef CHAR
typedef unsigned char Foo;
#else
enum class Foo : unsigned char { FOO };
#endif
unsigned int v1, v2;
__attribute__((noinline, noclone)) static void
foo (Foo a)
{
v1 = (unsigned int) a;
}
__attribute__((noinline, noclone)) void
bar (Foo a)
{
v2 = (unsigned int) a;
}
void
baz (unsigned int a)
{
foo ((Foo) a);
bar ((Foo) a);
}
with -DCHAR vs. -UCHAR, there is a difference visible already in *.original
dump:
cleanup_point Unknown tree: expr_stmt
- foo ((int) (Foo) a) ;
+ foo ((Foo) a) ;
cleanup_point Unknown tree: expr_stmt
- bar ((int) (Foo) a) ;
+ bar ((Foo) a) ;
i.e. there is explicit zero-extension for integral types smaller than int in
the IL (i.e. for the -DCHAR) case, but nothing like that for the enum class
with underlying type smaller than int. And presumably the middle-end and
backends rely on this.
[Bug c/63301] inconsistency on wchar_t and wint_t types and sizes for diverse architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63301 Joel Sherrill joel at gcc dot gnu.org changed: What|Removed |Added CC||joel at gcc dot gnu.org --- Comment #3 from Joel Sherrill joel at gcc dot gnu.org --- From my perspective, gcc needs to be reliable in reporting or not reporting warnings. When you can't write code that is warning free across all targets, it diminishes the value of the warning. Thanks for pointing out the code needs to be fixed. That is great. But .. read on.. I think you blew this off without considering how poorly gcc actually is doing on this warning. From what I can tell, gcc misses this warning on 2/3 of our targets and when you fix the code, has false positives on 1/3. And they aren't the same set. I would politely request that we reopen and recast this PR in that light. | gcc misses this on more targets than it catches it. It catches it on 6 of 18 targets. This is a pretty high false negative ratio. === arm-rtems4.11-gcc - no warning === avr-rtems4.11-gcc - no warning === bfin-rtems4.11-gcc - no warning === h8300-rtems4.11-gcc - no warning === i386-rtems4.11-gcc - no warning === lm32-rtems4.11-gcc - no warning === m68k-rtems4.11-gcc - warning === m32c-rtems4.11-gcc - warning === m32r-rtems4.11-gcc - no warning === mips-rtems4.11-gcc - no warning === moxie-rtems4.11-gcc - no warning === nios2-rtems4.11-gcc - no warning === or1k-rtems4.11-gcc - no warning === powerpc-rtems4.11-gcc - warning === sh-rtems4.11-gcc - warning === sparc64-rtems4.11-gcc - no warning === sparc-rtems4.11-gcc - warning === v850-rtems4.11-gcc - warning The test case is a cut down from the port of the FreeBSD hexdump command to RTEMS. I checked the current source at http://svnweb.freebsd.org/base/head/usr.bin/hexdump/conv.c?revision=247753view=markup and it uses %C at line 137 for the specifier. Modifying the test case accordingly, this changed the set of targets which gives a warning. Now 12 report it and 6 don't. It is a different set. This is with %C: === arm-rtems4.11-gcc - no warning === avr-rtems4.11-gcc - no warning === bfin-rtems4.11-gcc - no warning === h8300-rtems4.11-gcc - no warning === i386-rtems4.11-gcc - no warning === lm32-rtems4.11-gcc - no warning === m68k-rtems4.11-gcc - warning === m32c-rtems4.11-gcc - warning === m32r-rtems4.11-gcc - no warning === mips-rtems4.11-gcc - no warning === moxie-rtems4.11-gcc - no warning === nios2-rtems4.11-gcc - no warning === or1k-rtems4.11-gcc - no warning === powerpc-rtems4.11-gcc - warning === sh-rtems4.11-gcc - warning === sparc64-rtems4.11-gcc - no warning === sparc-rtems4.11-gcc - warning === v850-rtems4.11-gcc - warning
[Bug ipa/61998] [5 Regression] ICE: Segmentation fault with -Wsuggest-final-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61998 --- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Author: trippels Date: Fri Sep 19 14:44:09 2014 New Revision: 215392 URL: https://gcc.gnu.org/viewcvs?rev=215392root=gccview=rev Log: PR ipa/61998 Fix crash -Wsuggest-final-types crash -Wsuggest-final-types crashes when used on mininal testcases. Fix by bailing out early when odr_types_ptr is NULL in ipa_devirt() 2014-09-19 Markus Trippelsdorf mar...@trippelsdorf.de PR ipa/61998 * ipa-devirt.c (ipa_devirt): Bail out if odr_types_ptr is NULL. 2014-09-19 Markus Trippelsdorf mar...@trippelsdorf.de PR ipa/61998 * g++.dg/warn/Wsuggest-final-2.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/warn/Wsuggest-final-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-devirt.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/61998] [5 Regression] ICE: Segmentation fault with -Wsuggest-final-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61998 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |trippels at gcc dot gnu.org --- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org --- fixed.
[Bug target/63304] Aarch64 pc-relative load offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Status|RESOLVED|NEW Resolution|WONTFIX |--- Assignee|unassigned at gcc dot gnu.org |venkataramanan.kumar at amd dot co ||m Severity|normal |minor --- Comment #6 from Richard Earnshaw rearnsha at gcc dot gnu.org --- OK. But I still wouldn't loose much sleep over it. It wouldn't surprise me that if you turn the optimizer on it then blows up by using too much memory...
[Bug middle-end/63311] New: [4.9/5 Regression] -O1 optimization introduces valgrind warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63311 Bug ID: 63311 Summary: [4.9/5 Regression] -O1 optimization introduces valgrind warning Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch The following testcase yields a valgrind error when compiled with -O1 but not at -O0. 4.8 is fine 4.9/trunk is not. gfortran -O1 -g bug.f90 valgrind ./a.out ==57092== Conditional jump or move depends on uninitialised value(s) ==57092==at 0x4006F5: __m1_MOD_test (bug.f90:20) ==57092==by 0x4007BB: main (bug.f90:36) ==57092== ERROR SUMMARY: 4 errors from 1 contexts (suppressed: 6 from 6) cat bug.f90 MODULE M1 IMPLICIT NONE CONTAINS INTEGER FUNCTION foo() INTEGER, VOLATILE :: v=42 foo=v END FUNCTION SUBROUTINE test(n,flag) INTEGER :: n,i,j,k,l,tt LOGICAL :: flag REAL(KIND=8) :: v,t IF (flag) THEN t=42 tt=foo() ENDIF v=0 DO i=1,n v=0 IF (flag) THEN IF (tt==i) v=MAX(v,t) ENDIF DO j=1,n DO k=1,n v=MAX(v,sin(REAL(j*k))) ENDDO ENDDO ENDDO END SUBROUTINE END MODULE M1 USE M1 INTEGER :: n LOGICAL :: flag n=4 flag=.FALSE. CALL test(n,flag) END what seems to happen is that '(tt==i)' is evaluated before IF (flag) is evaluated, also in the case where 'flag==.FALSE.', while 'tt' is only initialized in the .TRUE. case. I actually think generated code might nevertheless be correct, but it makes valgrind less useful on -O1 code.
[Bug target/63312] New: FAIL: gcc.dg/torture/float128-exact-underflow.c -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63312 Bug ID: 63312 Summary: FAIL: gcc.dg/torture/float128-exact-underflow.c -O0 execution test Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: joseph at codesourcery dot com Target: ia64-*-* (gdb) bt #0 0xa0040721 in __kernel_syscall_via_break () #1 0x201b3190 in *__GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67 #2 0x201b5a70 in *__GI_abort () at abort.c:92 #3 0x4d30 in main () at ../../../../gcc/testsuite/gcc.dg/torture/float128-exact-underflow.c:39
[Bug target/56993] power gcc built 416.gamess generates wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993 --- Comment #10 from H.J. Lu hjl.tools at gmail dot com --- Created attachment 33517 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33517action=edit Here is my spec 2006 patch I need this patch on x86.
[Bug ipa/63313] New: ICE in ipa-comdats.c:371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63313 Bug ID: 63313 Summary: ICE in ipa-comdats.c:371 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: spop at gcc dot gnu.org Created attachment 33518 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33518action=edit Preprocessed testcase I get an ICE in ipa-comdats.c:371 when compiling system_error.cc from libstdc++: gcc -nostdinc++ -std=gnu++11 -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=system_error.lo -g -Os -c -fPIC foo.ii
[Bug testsuite/63305] ASan reported heap-buffer-overflow in gcc.target/i386/avx256-unaligned-load{store}-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63305 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-09-19 CC|hjl at gcc dot gnu.org |hjl.tools at gmail dot com Ever confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- Works for me: [hjl@gnu-mic-2 gcc]$ ./xgcc -B./ /export/gnu/import/git/gcc/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-7.c -fsanitize=address -O3 -dp -mavx -mavx256-split-unaligned-load -o /tmp/a.out -L../x86_64-unknown-linux-gnu/libsanitizer/asan/.libs -B../x86_64-unknown-linux-gnu/libsanitizer/asan/ -Wl,-R,../x86_64-unknown-linux-gnu/libsanitizer/asan/.libs [hjl@gnu-mic-2 gcc]$ /tmp/a.out [hjl@gnu-mic-2 gcc]$ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: x86_64-unknown-linux-gnu Configured with: /export/gnu/import/git/gcc/configure --enable-languages=c,c++ --disable-bootstrap --prefix=/usr/gcc-5.0.0 --with-local-prefix=/usr/local --enable-gnu-indirect-function --with-fpmath=sse Thread model: posix gcc version 5.0.0 20140916 (experimental) (GCC) [hjl@gnu-mic-2 gcc]$
[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #4 from mikulas at artax dot karlin.mff.cuni.cz ---
... and another related problem (try this on 32-bit system):
#include stdio.h
#include stdlib.h
int main(void)
{
short *a = malloc(0x5000 * sizeof(short));
short *b = a + 0x5000;
printf(%ld\n, (long)(b - a));
return 0;
}
Here, the return value should be positive (0x5000), but it is negative.
IMHO, according to the C standard, this is program correct and positive result
should be returned.
The problem is that it is not easy to fix it without performance penalty and
all compilers that I tried (gcc, clang, icc, suncc, opencc, nwcc) print
negative result.
[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to mikulas from comment #4)
... and another related problem (try this on 32-bit system):
#include stdio.h
#include stdlib.h
int main(void)
{
short *a = malloc(0x5000 * sizeof(short));
short *b = a + 0x5000;
printf(%ld\n, (long)(b - a));
return 0;
}
Here, the return value should be positive (0x5000), but it is negative.
IMHO, according to the C standard, this is program correct and positive
result should be returned.
This testcase is invalid, you really can't have an object bigger than half of
the address space in C/C++, pointer difference is signed ptrdiff_t and if you
have larger object, you can't subtract arbitrary char pointers in it anymore.
If you need more than 2GB in a single array, just use 64-bit system.
[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303 --- Comment #6 from mikulas at artax dot karlin.mff.cuni.cz --- you really can't have an object bigger than half of the address space in C/C++ - where does the standard claim this? If this is true, we should change malloc so that it doesn't allocate 2GiB or larger objects. Regarding pointer difference, the C standard says this: When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object; the result is the difference of the subscripts of the two array elements. The size of the result is implementation-defined, and its type (a signed integer type) is ptrdiff_t defined in the stddef.h header. If the result is not representable in an object of that type, the behavior is undefined. In other words, if the expressions P and Q point to, respectively, the i-th and j-th elements of an array object, the expression (P)-(Q) has the value i−j provided the value fits in an object of type ptrdiff_t. So: p points to the beginning, q points one past the last element, so the first condition is valid. The result is the difference of the subscripts of those two array elements: 0x5000 - 0 = 0x5000 - this is clearly representable in the type ptrdiff_t, so 0x5000 result should be returned.
[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303 --- Comment #7 from joseph at codesourcery dot com joseph at codesourcery dot com --- Yes, I consider it a bug in malloc that it produces objects 2GB or more in size on 32-bit systems (because of the one-past-end address, the largest size that can't produce undefined behavior in the user program is 2GB minus one byte). Unfortunately I expect some 32-bit applications rely on such large allocations, so if we changed malloc (please report a bug to glibc Bugzilla) we'd need a way (feature test macro?) for people to continue to build programs to use the old malloc, as well as to avoid breaking existing binaries.
[Bug debug/63300] 'const volatile' sometimes stripped in debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63300
Andreas Krebbel krebbel at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-09-19
CC||mark at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Andreas Krebbel krebbel at gcc dot gnu.org ---
Reghunt indicates that this is caused by r214143.
For a const volatile type none of the following IFs is triggered:
if ((cv_quals TYPE_QUAL_CONST)
/* If there are multiple type modifiers, prefer a path which
leads to a qualified type. */
(((cv_quals ~TYPE_QUAL_CONST) == TYPE_UNQUALIFIED)
|| get_qualified_type (type, cv_quals) == NULL_TREE
|| (get_qualified_type (type, cv_quals ~TYPE_QUAL_CONST)
!= NULL_TREE)))
{
mod_type_die = new_die (DW_TAG_const_type, mod_scope, type);
sub_die = modified_type_die (type, cv_quals ~TYPE_QUAL_CONST,
context_die);
}
else if ((cv_quals TYPE_QUAL_VOLATILE)
(((cv_quals ~TYPE_QUAL_VOLATILE) == TYPE_UNQUALIFIED)
|| get_qualified_type (type, cv_quals) == NULL_TREE
|| (get_qualified_type (type, cv_quals ~TYPE_QUAL_VOLATILE)
!= NULL_TREE)))
{
mod_type_die = new_die (DW_TAG_volatile_type, mod_scope, type);
sub_die = modified_type_die (type, cv_quals ~TYPE_QUAL_VOLATILE,
context_die);
}
else if (cv_quals TYPE_QUAL_RESTRICT)
{
mod_type_die = new_die (DW_TAG_restrict_type, mod_scope, type);
sub_die = modified_type_die (type, cv_quals ~TYPE_QUAL_RESTRICT,
context_die);
}
So the DIE ends up with an unqualified type.
[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to mikulas from comment #6) Regarding pointer difference, the C standard says this: When two pointers are subtracted, both shall point to elements of the same array object, or one past the last element of the array object; the result is the difference of the subscripts of the two array elements. The size of the result is implementation-defined, and its type (a signed integer type) is ptrdiff_t defined in the stddef.h header. If the result is not representable in an object of that type, the behavior is undefined. In other words, if the expressions P and Q point to, respectively, the i-th and j-th elements of an array object, the expression (P)-(Q) has the value i−j provided the value fits in an object of type ptrdiff_t. So: p points to the beginning, q points one past the last element, so the first condition is valid. The result is the difference of the subscripts of those two array elements: 0x5000 - 0 = 0x5000 - this is clearly representable in the type ptrdiff_t, so 0x5000 result should be returned. See what I wrote, any object size bigger than half of address space really isn't supportable, because then (char *) (P) - (char *) (Q) might not fit into ptrdiff_t. There is no point slowing down all pointer subtractions (other than char/signed char/unsigned char pointers) for something that really wouldn't work reliably anyway.
[Bug target/63312] FAIL: gcc.dg/torture/float128-exact-underflow.c -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63312 --- Comment #1 from Joseph S. Myers jsm28 at gcc dot gnu.org --- Created attachment 33519 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33519action=edit Untested patch Please try this patch. As I noted in my patch posting, the issue is that there is no ia64 definition of FP_TRAPPING_EXCEPTIONS.
[Bug ada/63310] Ada bootstrap error with -fcompare-debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63310 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-19 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- I have no idea what is dummy_global good for, but if you need it, it probably has to be created regardless of whether types_used_by_cur_var_decl vector is empty or not. There is a comment above the code but, if you can make it work without it, be my guest. Otherwise creating it unconditionally is fine with me, provided that the comment is updated accordingly.
[Bug lto/63286] [5 Regression] FAIL: g++.dg/lto/20101014-2 cp_lto_20101014-2_0.o assemble, * after r215196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63286 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- I am testing: Index: tree.c ... AFAICT the patch in comment 1 does not fix the PR.
[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303 --- Comment #9 from mikulas at artax dot karlin.mff.cuni.cz --- See what I wrote, any object size bigger than half of address space really isn't supportable, because then (char *) (P) - (char *) (Q) might not fit into ptrdiff_t. There is no point slowing down all pointer subtractions (other than char/signed char/unsigned char pointers) for something that really wouldn't work reliably anyway. But the code in comment 4 doesn't perform (char *)P - (char *)Q. It performs (short *)P - (short *)Q. And that result clearly fits into the signed ptrdiff_t type. If the code in comment 4 performed (char *)b - (char *)a, that operation would be invalid because of overflow. But it doesn't.
[Bug middle-end/63244] [4.9 regression] internal compiler error: Segmentation fault (program cc1plus)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63244 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ccoutant at gcc dot gnu.org
[Bug libstdc++/63314] New: valarray mask/indices refers to temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63314
Bug ID: 63314
Summary: valarray mask/indices refers to temporary
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: helloworld922 at hotmail dot com
std::mask_array appears to be holding a reference to the underlying _M_data of
the mask std::valarray. This is a problem when the mask valarray is a
temporary:
std::valarrayint data = {1,4,0,2,5};
std::mask_arrayint marr = data[data = 2];
Here, the data = 2 mask is a temporary and sarr will have an invalid address
for for the mask _M_data. Trying to do anything with mask_array at this point
would have problems, i.e.:
marr = 11;
will be undefined behavior.
Similarly, there is an identical issue with std::indirect_array:
std::indirect_arrayint iarr = data[std::valarraysize_t({1,2,4})];
Because the underlying _M_data has no ownership in mask_array/indirect_array,
there are additional problems when trying to return the given type:
std::mask_arrayint doit(const std::valarrayint data)
{
std::valarraysize_t idx = {1,2,3};
return data[idx];
}
It is unclear to me if this behavior is allowed by the standard, but it
certainly looks fishy, especially given that the deduced type for this:
auto marr = data[data = 2];
is std::mask_array
[Bug debug/63300] 'const volatile' sometimes stripped in debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63300 --- Comment #2 from Mark Wielaard mark at gcc dot gnu.org --- Sorry about that. I added an explicit testcases (gcc/testsuite/gcc.dg/guality/const-volatile.c and gcc/testsuite/gcc.dg/guality/restrict.c) explicitly to catch such issue. But apparently they didn't trigger this particular case.
[Bug target/63304] Aarch64 pc-relative load offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304 Venkataramanan venkataramanan.kumar at amd dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||doko at ubuntu dot com Resolution|--- |WONTFIX --- Comment #7 from Venkataramanan venkataramanan.kumar at amd dot com --- Ok I am closing this as wont fix now. Checked with Mitthias who reported the problem to us and he is fine building it with -O2.
