[Bug libstdc++/60966] std::call_once sometime hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966 --- Comment #12 from Thomas Sanchez --- Hi Hideaki, I was able to workaround the bug by using boost promise instead of the STL one. I did not have the time to investigate the bug however, I'm not really familiar with the STL design :( Here is what I needed to do: https://github.com/daedric/httpp/commit/b7d9a36c7a9fe9fdaed1771326c1c5e5eaaa507c I did not hit the problem again so far. Good luck ! Are you able to produce a smaller code which trigger the bug than I was?
[Bug lto/60981] lto-plugin configuration doesn't test for -static-libgcc (OSX gcc -> clang)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60981 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||https://gcc.gnu.org/ml/gcc- ||patches/2014-05/msg01047.ht ||ml Last reconfirmed||2014-05-14 Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org Target Milestone|--- |4.9.1 Ever confirmed|0 |1 --- Comment #7 from Rainer Orth --- Patch submitted.
[Bug sanitizer/61100] asan/tsan should have the sanitizer includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61100 --- Comment #2 from ygribov at gcc dot gnu.org --- Author: ygribov Date: Wed May 14 08:33:45 2014 New Revision: 210413 URL: http://gcc.gnu.org/viewcvs?rev=210413&root=gcc&view=rev Log: 2014-05-14 Yury Gribov PR sanitizer/61100 * Makefile.am (nodist_saninclude_HEADERS): Install public headers. * Makefile.in: Regenerate. * c-c++-common/asan/asan-interface-1.c: New test. * lib/asan-dg.exp (asan_include_flags): New function. (asan_init): Call asan_include_flags to obtain path to sanitizer headers. Added: trunk/gcc/testsuite/c-c++-common/asan/asan-interface-1.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/asan-dg.exp trunk/libsanitizer/ChangeLog trunk/libsanitizer/Makefile.am trunk/libsanitizer/Makefile.in
[Bug sanitizer/61100] asan/tsan should have the sanitizer includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61100 --- Comment #3 from Yury Gribov --- Kostya, please check if this works for you. Also you'll probably want to update the file list in the upcoming patch.
[Bug sanitizer/61100] asan/tsan should have the sanitizer includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61100 Kostya Serebryany changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Kostya Serebryany --- Excellent, thank you!
[Bug plugins/61176] [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176
--- Comment #2 from Matthias Klose ---
is this about stability? With trying, you find out that the following will
work:
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int main(void) {
return 0;
}
is there any way to find out all the needed includes? Telling plugin writers
to hard-code all of this doesn't seem like a viable solution.
[Bug c/61184] [4.10 Regression] wrong code (that hangs) by LTO on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61184
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Keywords||wrong-code
Last reconfirmed||2014-05-14
Component|lto |c
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
Summary|wrong code (that hangs) by |[4.10 Regression] wrong
|LTO on x86_64-linux-gnu |code (that hangs) by LTO on
||x86_64-linux-gnu
Target Milestone|--- |4.10.0
--- Comment #1 from Richard Biener ---
Confirmed. VRP2 transforms this wrongly. Can be reproduced without LTO
and just with -Os -fno-strict-overflow.
It boils down to gimplification optimizing the auto-inc in short as if
overflow would wrap. But -fno-strict-overflow does _not_ say overflow
wraps. It just says we don't treat as many things as overflowing
(yeah, quite useless).
Thus we may not do:
case PREINCREMENT_EXPR:
case PREDECREMENT_EXPR:
case POSTINCREMENT_EXPR:
case POSTDECREMENT_EXPR:
{
tree type = TREE_TYPE (TREE_OPERAND (*expr_p, 0));
if (INTEGRAL_TYPE_P (type) && c_promoting_integer_type_p (type))
{
if (TYPE_OVERFLOW_UNDEFINED (type)
|| ((flag_sanitize & SANITIZE_SI_OVERFLOW)
&& !TYPE_OVERFLOW_WRAPS (type)))
type = unsigned_type_for (type);
return gimplify_self_mod_expr (expr_p, pre_p, post_p, 1, type);
}
break;
}
but have to use !TYPE_OVERFLOW_WRAPS (type) - sanitization should have
shown this.
So it's not really a 4.10 regression only, but latent (and thus not really a
regression).
[Bug c++/61182] [4.9/4.10 Regression] Forming pointer to qualified function type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182 Paolo Carlini changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com Summary|Forming pointer to |[4.9/4.10 Regression] |qualified function type |Forming pointer to ||qualified function type --- Comment #6 from Paolo Carlini --- Thanks. I was also going through that section (together with Core/1417 submitted by Daniel, and other issues) and indeed, not having followed this tangle of issues of the years I was tempted to interpret it the same way. I'm adding Daniel in CC, maybe he has a something to say. To be safe, I'm also tentatively marking this as a regression.
[Bug rtl-optimization/60901] [4.8/4.9/4.10 Regression] ICE: SIGSEGV in add_to_deps_list with -fsel-sched-pipelining-outer-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60901 --- Comment #4 from Andrey Belevantsev --- Author: abel Date: Wed May 14 09:46:26 2014 New Revision: 210414 URL: http://gcc.gnu.org/viewcvs?rev=210414&root=gcc&view=rev Log: PR rtl-optimization/60901 * config/i386/i386.c (ix86_dependencies_evaluation_hook): Check that bb predecessor belongs to the same scheduling region. Adjust comment. * gcc.target/i386/pr60901.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr60901.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/60901] [4.8/4.9/4.10 Regression] ICE: SIGSEGV in add_to_deps_list with -fsel-sched-pipelining-outer-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60901 Andrey Belevantsev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrey Belevantsev --- Fixed on trunk.
[Bug plugins/61176] [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- IMHO the header flattening is a serious mistake, but others think otherwise :(.
[Bug sanitizer/61185] New: Wrong value in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61185
Bug ID: 61185
Summary: Wrong value in error message
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
int
main ()
{
unsigned i = 32, j = 40;
int u = 9;
u <<= i - j;
}
with -fsanitize=shift says
s.c:6:5: runtime error: shift exponent -8 is negative
but it should say
s.c:6:5: runtime error: shift exponent 4294967288 is too large for 32-bit type
'int'
[Bug sanitizer/61185] Wrong value in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61185 Marek Polacek changed: What|Removed |Added Target Milestone|--- |4.10.0 --- Comment #1 from Marek Polacek --- And the reason is that we convert the (i - j) to int here: 10501 /* Convert the non vector shift-count to an integer, regardless 10502 of size of value being shifted. */ 10503 if (TREE_CODE (TREE_TYPE (op1)) != VECTOR_TYPE 10504 && TYPE_MAIN_VARIANT (TREE_TYPE (op1)) != integer_type_node) 10505 op1 = convert (integer_type_node, op1);
[Bug middle-end/61158] negative shift at fold-const.c:12095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61158 --- Comment #3 from Marek Polacek --- (In reply to Vittorio Zecca from comment #2) > I found this one with -fsanitize=shift. The runtime error message says > "shift exponent -8 is negative". Maybe this is also a sanitizer bug? Yeah, I opened PR61185.
[Bug sanitizer/61185] Wrong value in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61185 --- Comment #2 from Jakub Jelinek --- IMHO not a bug. The compiler really uses (int) (i - j) as the shiftcount, and that is negative.
[Bug sanitizer/61185] Wrong value in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61185
--- Comment #3 from Jakub Jelinek ---
But, if you want to use the source type before this conversion, make sure to
also
test stuff like:
int
main ()
{
unsigned long long l = 0x0001ULL;
volatile int u = 9;
u <<= l;
return 0;
}
where the shift count after (int) conversion is in range, while before the
conversion it is not (ILP32 and LP64 targets only here).
[Bug fortran/60928] gfortran issue with allocatable components and OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60928 --- Comment #5 from Sean Santos --- Well, I thought I understood this, but maybe not. I was thinking that "subobject" in this context meant "component". A "list item" here is just any variable or common block listed in a clause, in this case the private clause. And "allocatable" would have to apply to the component, not the variable, because otherwise it would make no sense to say that the subobject has an allocation status. So in this interpretation, the third and fourth examples you list would be perfectly valid cases. The problem with that is that Fortran 2003 defines "subobject" in a way that can include array sections, and OpenMP 4.0 also allows "list item" to refer to an array section. So there's an alternative interpretation here, which is that all this "subobject" stuff is just a very poorly worded way of referring to the fact that you can have a section of an array be thread private. (But then it is still kind of strange to talk about the "allocation status" of an array section.) Anyway, I retract what I said before. It's not clear to me what the standard is trying to say, and just as plausible that this is trying to refer to array sections as to derived type components.
[Bug fortran/60928] gfortran issue with allocatable components and OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60928 --- Comment #6 from Jakub Jelinek --- Array sections are only allowed in depend, map, from and to clauses, other clauses work only with whole variables, not just portions thereof.
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #4 from wangzheyu --- Hi christophe, It's ok from my side, the link time is ok. I'm not sure if it's related to your tool chain version, but would you please provide detailed information of your toolchain, the cmd you run for the test case, and where you get this version binutils? (In reply to christophe.lyon from comment #3) > Sorry I no longer have the elf file available. > I've just looked at the current trunk status and I have a failure at link > time for these tests: > ld: gcc_tg.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not > be used when making a shared object; recompile with -fPIC > gcc_tg.o: error adding symbols: Bad value > collect2: error: ld returned 1 exit status > compiler exited with status 1 > > Not sure if it's a problem with the binutils I use (linaro-2.24-2013.12) or > a known problem with the GCC test?
[Bug middle-end/61158] negative shift at fold-const.c:12095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61158 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-14 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Jakub Jelinek --- Created attachment 32795 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32795&action=edit gcc49-pr61158.patch Untested fix. If prec >= shiftc, then the result is always 0, as we shift away all the possibly non-zero bits. Therefore, we should just optimize it into (X, 0).
[Bug libstdc++/60966] std::call_once sometime hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966 --- Comment #13 from Jonathan Wakely --- (In reply to Hideaki Kimura from comment #11) > Hi, I'm also (seemingly) hitting this issue. > When I run my program with valgrind, I get what Thomas reported. > > ==22319== Invalid read of size 4 > ==22319==at 0x370940D201: pthread_once (pthread_once.S:111) > ==22319==by 0x4C80524: (gthr-default.h:699) > ... > ==22319== Address 0x52c52a4 is 132 bytes inside a block of size 136 free'd > ==22319==at 0x4A07991: operator delete(void*) (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==22319==by 0x4C82456: ... (shared_ptr_base.h:161) > ==22319==by 0x370C4B52AF: execute_native_thread_routine (thread.cc:84) > ==22319==by 0x3709407F32: start_thread (pthread_create.c:309) > ==22319==by 0x37090F4DEC: clone (clone.S:111) > ==22319== This means you are waiting on an object that has gone out of scope. WIthout more information it's not possible to tell if this is a bug in your program or the standard libary. I'll try to reproduce it with Thomas's code...
[Bug c++/61182] [4.9/4.10 Regression] Forming pointer to qualified function type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182
--- Comment #7 from Jonathan Wakely ---
(In reply to pdaouadi from comment #3)
> Still, if the standard says that it is not allowed we can work around it,
> but then should I file a bug to clang?
And Boost. I have to wonder why their remove_const is so much more complicated
than ours:
template
struct remove_const
{ typedef _Tp type; };
template
struct remove_const<_Tp const>
{ typedef _Tp type; };
That doesn't need to form a pointer then remove it again, so works with
function types.
[Bug sanitizer/61185] Wrong value in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61185 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Marek Polacek --- Ok, I guess it's not worth it. Closing.
[Bug c++/61182] [4.9/4.10 Regression] Forming pointer to qualified function type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182 --- Comment #8 from Daniel Krügler --- (In reply to Paolo Carlini from comment #6) > I'm adding Daniel in CC, maybe he has a something to say. To be safe, I'm > also tentatively marking this as a regression. I agree with Jason as well for the reasons the quoted CWG issue 1417 had clarified. This is also one reason, why the current library specification of std::add_pointer needs to be corrected, see http://cplusplus.github.io/LWG/lwg-active.html#2101
[Bug c++/61182] [4.9/4.10 Regression] Forming pointer to qualified function type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182
--- Comment #9 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #7)
> And Boost. I have to wonder why their remove_const is so much more
> complicated than ours:
>
> template
> struct remove_const
> { typedef _Tp type; };
>
> template
> struct remove_const<_Tp const>
> { typedef _Tp type; };
>
> That doesn't need to form a pointer then remove it again, so works with
> function types.
I don' think that this specialization can - according to the language - remove
const qualifiers of function types, because there is no const-qualifier to
remove. As far as I remember the core language makes this possible when
rewriting the specialization to be one for a function type, as of core wording
resolution
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#547
[Bug rtl-optimization/60866] [4.7/4.8/4.9/4.10 Regression] ICE: in get_seqno_for_a_jump, at sel-sched-ir.c:4068 with -fselective-scheduling -fno-if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60866 --- Comment #4 from Andrey Belevantsev --- Author: abel Date: Wed May 14 12:09:02 2014 New Revision: 210420 URL: http://gcc.gnu.org/viewcvs?rev=210420&root=gcc&view=rev Log: PR rtl-optimization/60866 * sel-sched-ir (sel_init_new_insn): New parameter old_seqno. Default it to -1. Pass it down to init_simplejump_data. (init_simplejump_data): New parameter old_seqno. Pass it down to get_seqno_for_a_jump. (get_seqno_for_a_jump): New parameter old_seqno. Use it for initializing new jump seqno as a last resort. Add comment. (sel_redirect_edge_and_branch): Save old seqno of the conditional jump and pass it down to sel_init_new_insn. (sel_redirect_edge_and_branch_force): Likewise. * gcc.dg/pr60866.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr60866.c Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched-ir.c trunk/gcc/testsuite/ChangeLog
[Bug plugins/61176] [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 --- Comment #4 from Andrew Macleod --- We have to flatten it before we can fix it... its a complete dependency mess. you could create a plugin-includes.h which includes all the files from the primary globbing files that were flattened (gimple.h and tree.h). Start by copying all the original includes from those 2 files. Then each plugin doesn't have to figure out what it needs... at least until we get back to a reasonable state.
[Bug c++/61186] New: ./g++.dg/ipa/pr52939.C & valgrind & pointer_set_insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61186 Bug ID: 61186 Summary: ./g++.dg/ipa/pr52939.C & valgrind & pointer_set_insert Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com For today's trunk build of gcc $ valgrind -q --trace-children=yes ~/gcc/results/bin/gcc -c -O2 ./g++.dg/ipa/pr52939.C ==1427== Use of uninitialised value of size 8 ==1427==at 0x9C54B2: pointer_set_insert(pointer_set_t*, void const*) (pointer-set.c:90) ==1427==by 0x8FAB2E: symtab_remove_unreachable_nodes(bool, _IO_FILE*) (ipa.c:180) ==1427==by 0x754B5D: compile() [clone .part.29] (cgraphunit.c:2052) ==1427==by 0x75525D: finalize_compilation_unit() (cgraphunit.c:2151) ==1427==by 0x5B73DB: cp_write_global_declarations() (decl2.c:4626) ==1427==by 0xA92CAC: compile_file() (toplev.c:562) ==1427==by 0xA948F1: toplev_main(int, char**) (toplev.c:1915) ==1427==by 0x32C5E21D64: (below main) (libc-start.c:285) ==1427== ==1427== Conditional jump or move depends on uninitialised value(s) ==1427==at 0x9C54B8: pointer_set_insert(pointer_set_t*, void const*) (pointer-set.c:90) ==1427==by 0x8FAB2E: symtab_remove_unreachable_nodes(bool, _IO_FILE*) (ipa.c:180) ==1427==by 0x754B5D: compile() [clone .part.29] (cgraphunit.c:2052) ==1427==by 0x75525D: finalize_compilation_unit() (cgraphunit.c:2151) ==1427==by 0x5B73DB: cp_write_global_declarations() (decl2.c:4626) ==1427==by 0xA92CAC: compile_file() (toplev.c:562) ==1427==by 0xA948F1: toplev_main(int, char**) (toplev.c:1915) ==1427==by 0x32C5E21D64: (below main) (libc-start.c:285) ==1427== ==1427== Use of uninitialised value of size 8 ==1427==at 0x9C54C8: pointer_set_insert(pointer_set_t*, void const*) (pointer-set.c:150) ==1427==by 0x8FAB2E: symtab_remove_unreachable_nodes(bool, _IO_FILE*) (ipa.c:180) ==1427==by 0x754B5D: compile() [clone .part.29] (cgraphunit.c:2052) ==1427==by 0x75525D: finalize_compilation_unit() (cgraphunit.c:2151) ==1427==by 0x5B73DB: cp_write_global_declarations() (decl2.c:4626) ==1427==by 0xA92CAC: compile_file() (toplev.c:562) ==1427==by 0xA948F1: toplev_main(int, char**) (toplev.c:1915) ==1427==by 0x32C5E21D64: (below main) (libc-start.c:285) ==1427== $ ~/gcc/results/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/dcb/gcc/results/bin/gcc COLLECT_LTO_WRAPPER=/home/dcb/gcc/results/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../src/trunk/configure --prefix=/home/dcb/gcc/results --enable-checking=release --enable-languages=c,c++,fortran --disable-werror Thread model: posix gcc version 4.10.0 20140514 (experimental) (GCC) [dcb@zippy4 testsuite]$
[Bug rtl-optimization/60866] [4.7/4.8/4.9/4.10 Regression] ICE: in get_seqno_for_a_jump, at sel-sched-ir.c:4068 with -fselective-scheduling -fno-if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60866 Andrey Belevantsev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.10.0 Resolution|--- |FIXED Known to fail|4.10.0 | --- Comment #5 from Andrey Belevantsev --- Fixed on trunk.
[Bug plugins/61176] [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 --- Comment #5 from Andrew Macleod --- btw, the long term plan is that #include "gimple.h" will get all the basic prerequisites you need to manipulate gimple. And then you just #include any extras your specific task requires. We're just in a transition state this release as we flatten to reconstruct a more sensible modular layout.
[Bug plugins/61176] [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 --- Comment #6 from Matthias Klose --- Am 14.05.2014 14:21, schrieb amacleod at redhat dot com: > btw, the long term plan is that #include "gimple.h" will get all the basic > prerequisites you need to manipulate gimple. And then you just #include any > extras your specific task requires. We're just in a transition state this > release as we flatten to reconstruct a more sensible modular layout. this is for 4.10, but what to do about 4.9? Maybe have gimple-plugin.h and tree-plugin.h headers, which won't go away for 4.10 and then would just include gimple.h and tree.h? I would appreciate if you could name all the toplevel headers.
[Bug libfortran/61187] New: valgrind errors if stdin is closed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61187 Bug ID: 61187 Summary: valgrind errors if stdin is closed Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: jb at gcc dot gnu.org In some cases STDIN_FILENO (0 in POSIX) can be closed. This happens e.g. for rank != 0 MPI processes with MPICH2. This results in valgrind complaining about uninitialized variables. Test program: ! Compile and run with ! gfortran -g otest.f90 ! mpirun -np 2 valgrind --track-origins=yes a.out program otest implicit none print *, "hello" end program Running via mpirun from mvapich2 1.8 and gcc 4.9.0 and strace shows: fstat(0, fstat(0, 0x74ee09d0)= -1 EBADF (Bad file descriptor) In unix.c(fd_to_stream) we don't check the return value of fstat before accessing statbuf. See https://gcc.gnu.org/ml/fortran/2014-04/msg00081.html for original bug report.
[Bug debug/61188] New: [4.10 regression] Many -fcompare-debug failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61188
Bug ID: 61188
Summary: [4.10 regression] Many -fcompare-debug failures
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: rdsandiford at googlemail dot com
Host: sparc-sun-solaris2.11
Target: sparc-sun-solaris2.11
Build: sparc-sun-solaris2.11
Between 20140509 (r210264) and 20140513 (r210366) there occured many new
testsuite
failures on Solaris 11/SPARC (both with as and gas), all of them
-fcompare-debug
failures, it seems, e.g.
FAIL: gcc.dg/autopar/pr46066.c (test for excess errors)
% /var/gcc/regression/trunk/11-gcc/build/gcc/xgcc
-B/var/gcc/regression/trunk/11-gcc/build/gcc/
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/autopar/pr46066.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -fcompare-debug -O
-ftree-parallelize-loops=4 -S -o pr46066.s
xgcc: error:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/autopar/pr46066.c:
-fcompare-debug failure (length)
The .gkd differences look like this:
--- pr46066.gkd 2014-05-14 14:56:34.164811700 +0200
+++ pr46066.gk.gkd 2014-05-14 14:56:34.320700300 +0200
@@ -31,7 +31,7 @@
(const_int 0 [0])))
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.d
g/autopar/pr46066.c:10# {*cmpsi_insn}
(nil))
(insn 0 0 0 (sequence [
-(jump_insn 33 # # (set (pc)
+(jump_insn 35 # # (set (pc)
(if_then_else (le (reg:CC 100 %icc)
(const_int 0 [0]))
(label_ref:SI #)
@@ -39,7 +39,7 @@
(expr_list:REG_DEAD (reg:CC 100 %icc)
(int_list:REG_BR_PROB 900 (nil)))
-> 17)
-(insn 38 # # (set (reg:SI 1 %g1 [156])
+(insn 40 # # (set (reg:SI 1 %g1 [156])
(const_int 15360 [0x3c00]))# {*movsi_insn}
(expr_list:REG_EQUIV (const_int 15360 [0x3c00])
(nil)))
I'm attaching the full files.
I suspect that this is related to
2014-05-13 Richard Sandiford
* rtl.def (DEBUG_INSN, INSN, JUMP_INSN, CALL_INSN, JUMP_TABLE_DATA)
(BARRIER, CODE_LABEL, NOTE): Remove first "i" field.
* rtl.h (rtx_def): Add insn_uid to u2 field.
(RTX_FLAG_CHECK8): Delete in favor of...
(RTL_INSN_CHAIN_FLAG_CHECK): ...this new macro.
(INSN_DELETED_P): Update accordingly.
(INSN_UID): Use u2.insn_uid.
(INSN_CHAIN_CODE_P): Define.
(PREV_INSN, NEXT_INSN, BLOCK_FOR_INSN, PATTERN, INSN_LOCATION)
(INSN_CODE, REG_NOTES, CALL_INSN_FUNCTION_USAGE, CODE_LABEL_NUMBER)
(NOTE_DATA, NOTE_DELETED_LABEL_NAME, NOTE_BLOCK, NOTE_EH_HANDLER)
(NOTE_BASIC_BLOCK, NOTE_VAR_LOCATION, NOTE_CFI, NOTE_LABEL_NUMBER)
(NOTE_KIND, LABEL_NAME, LABEL_NUSES, JUMP_LABEL, LABEL_REFS): Lower
indices accordingly.
* print-rtl.c (print_rtx): Print INSN_UIDs before the main loop.
Update indices for insn-chain rtxes.
* gengtype.c (gen_rtx_next): Adjust test for insn-chain rtxes.
(adjust_field_rtx_def): Lower '0' indices for all insn-chain rtxes.
* emit-rtl.c (gen_label_rtx): Update gen_rtx_LABEL call.
* caller-save.c (init_caller_save): Update gen_rtx_INSN calls.
* combine.c (try_combine): Likewise.
* ira.c (setup_prohibited_mode_move_regs): Likewise.
Rainer
[Bug debug/61188] [4.10 regression] Many -fcompare-debug failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61188 --- Comment #1 from Rainer Orth --- Created attachment 32796 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32796&action=edit -fcompare-debug dump
[Bug debug/61188] [4.10 regression] Many -fcompare-debug failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61188 --- Comment #2 from Rainer Orth --- Created attachment 32797 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32797&action=edit -fcompare-debug dump
[Bug debug/61188] [4.10 regression] Many -fcompare-debug failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61188 Rainer Orth changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug tree-optimization/61090] [4.10 Regression] ICE in build_ref_for_offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61090 Martin Jambor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org --- Comment #2 from Martin Jambor --- Mine.
[Bug rtl-optimization/60866] [4.7/4.8/4.9 Regression] ICE: in get_seqno_for_a_jump, at sel-sched-ir.c:4068 with -fselective-scheduling -fno-if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60866 Uroš Bizjak changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |--- Summary|[4.7/4.8/4.9/4.10 |[4.7/4.8/4.9 Regression] |Regression] ICE: in |ICE: in |get_seqno_for_a_jump, at|get_seqno_for_a_jump, at |sel-sched-ir.c:4068 with|sel-sched-ir.c:4068 with |-fselective-scheduling |-fselective-scheduling |-fno-if-conversion |-fno-if-conversion --- Comment #6 from Uroš Bizjak --- Not yet fixed on release branches.
[Bug libstdc++/61166] overflow when parse number in std::duration operator""
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61166 --- Comment #6 from emsr at gcc dot gnu.org --- Something like parse_number was in the original doc as an implementation example. The idea was to select the smallest integral type that could accommodate the number string with. This is done with _Select_int. _Select_type picks the most space-efficient duration ratio type using _Select_int.
[Bug plugins/61176] [4.9/4.10 Regression] plugin builds including gimple.h not building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176 --- Comment #7 from Andrew Macleod --- Thats part of the fun. There is little rhyme nor reason to what includes what right now.. it was purely demand driven over many years. For your current purposes, gimple.h and tree.h were the primary accumulators we have already flattened, but there are a lot of include files which include 4 or 5 or 7 or more other files. Some where flattened, others haven't been tackled yet. We're trying to move to the include what you use model... with .h files containing just the exports for their .c file, and a few module headers which do some aggregation of common/required headers. Eventually including gimple.h alone will compile and provide basic manipulation routines, but you may still need to include other files depending on what you actually require. Plugins can either follow the same model, or could have one giant accumulator which includes everything... It sounds like the latter may be better for the interm, but I would encourage it to revert to the same model once the work is complete.
[Bug c++/61182] [4.9/4.10 Regression] Forming pointer to qualified function type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182 --- Comment #10 from pdaou...@aldebaran-robotics.com --- (In reply to Daniel Krügler from comment #9) > I don' think that this specialization can - according to the language - > remove const qualifiers of function types, because there is no > const-qualifier to remove. remove_const does not remove const from functions even in previous function of gcc and I do not expect it to do that. I expect it to give the same type, unchanged as it does with gcc < 4.9.
[Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094 --- Comment #9 from Jeffrey A. Law --- Just starting to look at this, but my first thought is to validate the copy in combine_set_extension. We can still abort the transformation at that point.
[Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094 --- Comment #10 from Jakub Jelinek --- Sure, there, or merge_def_and_ext, or combine_reaching_defs. In any case, what I'm afraid of is that when there are two extensions, you in the first round verify that a copy is suitable and so is the new extension insn, but then you widen the extension insn even further, the widening succeeds, but nothing verifies the copy insn that is now to be performed in the even wider mode compared from what has been verified earlier. And in the wider mode it might be unsupported.
[Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094 --- Comment #11 from Jeffrey A. Law --- Right, and that's the case I'm still pondering.
[Bug libstdc++/61166] overflow when parse number in std::duration operator""
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61166
--- Comment #7 from Kan Liu ---
(In reply to emsr from comment #6)
> Something like parse_number was in the original doc as an implementation
> example. The idea was to select the smallest integral type that could
> accommodate the number string with. This is done with _Select_int.
> _Select_type picks the most space-efficient duration ratio type using
> _Select_int.
Yeah, but it only helps saving space when compiling time for now. For now
implementation, _Select_type takes the default chrono::hour (and other time
units), which uses *int64_t* as its underlying representation. So, it doesn't
save space I think.
Take *ms* as example
Implementation now:
template
constexpr typename
__select_type::_Select_type<__select_int::_Select_int<_Digits...>::value,
chrono::milliseconds>::type
operator""ms()
{
return __select_type::_Select_type<
__select_int::_Select_int<_Digits...>::value,
chrono::milliseconds>::value;
}
space-efficient version (maybe), get the type from _Select_int:
template
constexpr typename
chrono::duration::value), milli>
operator""_ms()
{
typedef typename __select_int::_Select_int<_Digits...> __selected;
typedef typename chrono::duration
__duration_type;
return __duration_type {__selected::value};
}
[Bug debug/61013] [4.9/4.10 Regression] Option parsing difference between < 4.9 and 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #11 from Tom Tromey --- FWIW this regresses a few gdb tests. It's easy to fix the gdb test suite, but if this is going to be fixed before the next gcc release, I'd rather not bother. Any word on that?
[Bug debug/61013] [4.9/4.10 Regression] Option parsing difference between < 4.9 and 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 --- Comment #12 from ccoutant at google dot com --- > FWIW this regresses a few gdb tests. It's easy to fix the > gdb test suite, but if this is going to be fixed before the > next gcc release, I'd rather not bother. Any word on that? I'm planning to fix it as proposed above, and backport to the 4.9 branch -- I was just waiting to hear back from rth. -cary
[Bug c++/56176] ICE with call to synthesized default constructor of inner struct with NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56176 --- Comment #3 from Paolo Carlini --- I'm going to add the reduced testcase and close this as fixed.
[Bug c++/58616] [meta-bug] nsdmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58616 Bug 58616 depends on bug 56176, which changed state. Bug 56176 Summary: ICE with call to synthesized default constructor of inner struct with NSDMI https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56176 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/56176] ICE with call to synthesized default constructor of inner struct with NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56176 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Paolo Carlini --- In fact we already got nsdmi-defer6.C.
[Bug gcov-profile/60897] Mangled function name in warning during -fprofile-use phase of Firefox build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60897 --- Comment #4 from Martin Jambor --- Author: jamborm Date: Wed May 14 15:32:31 2014 New Revision: 210426 URL: http://gcc.gnu.org/viewcvs?rev=210426&root=gcc&view=rev Log: 2014-05-14 Martin Jambor PR ipa/60897 * ipa-prop.c (ipa_modify_formal_parameters): Reset DECL_LANG_SPECIFIC. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c
[Bug bootstrap/61084] [4.10 regression] wide-int merge broke Solaris/SPARC bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61084 --- Comment #9 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Wed May 14 15:42:52 2014 New Revision: 210428 URL: http://gcc.gnu.org/viewcvs?rev=210428&root=gcc&view=rev Log: gcc/ PR target/61084 * config/sparc/sparc.md: Fix types of low and high in DI constant splitter. Use gen_int_mode in some other splitters. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.md
[Bug debug/61188] [4.10 regression] Many -fcompare-debug failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61188 --- Comment #3 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Wed May 14 15:53:11 2014 New Revision: 210429 URL: http://gcc.gnu.org/viewcvs?rev=210429&root=gcc&view=rev Log: gcc/ PR debug/61188 * print-rtl.c (print_rtx): Suppress uids if flag_dump_unnumbered. Modified: trunk/gcc/ChangeLog trunk/gcc/print-rtl.c
[Bug debug/61188] [4.10 regression] Many -fcompare-debug failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61188 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||rsandifo at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from rsandifo at gcc dot gnu.org --- Fixed -- sorry for the breakage.
[Bug lto/61001] Builtin memcpy and memset cannot be overridden when -flto is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61001 Emmanuel Blot changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Emmanuel Blot --- (In reply to Hans-Peter Nilsson from comment #3) > (In reply to Marc Glisse from comment #2) > > -fno-builtin-memcmp is not a hack, it is necessary, even without -flto. > > Without it, linking is not the only thing that may fail. gcc may look at > > your implementation, recognize that it is doing the same thing as memcmp, > > and replace it with a call to memcmp... > > True in part. Each code implementing the standard NAME function should > themselves be compiled with the corresponding -fno-builtin-NAME. But other > than that, there should be no restrictions or required options. There are > likely bugs hiding (like, -flto combined with compiling the implementation > of such a function) so PLEASE: > > Provide a test-case or you'll at most receive cryptic comments like this one. Sorry about the delay, I've been out of the office for 2 weeks. I spent some time reproducing the issue with a small code base (2 source files + 1 linker file), then I realised I was misusing the -fno-builtin-NAME option switch. With -fno-builtin-memcpy -fno-builtin-memset properly set, both the sample test case and the original code work as expected. Thanks for the support, and very sorry for the noise, I did not know about the -fno-builtin-NAME flag.
[Bug c++/61189] New: ICE with __builtin_return_address() in noexcept lambda on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61189
Bug ID: 61189
Summary: ICE with __builtin_return_address() in noexcept lambda
on x86
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Minimal test case:
void foo(){
[]() noexcept { return __builtin_return_address(0); }();
}
Compiled with:
E:\Desktop>g++ test.cpp -std=c++1y
test.cpp: In lambda function:
test.cpp:2:54: internal compiler error: in ix86_compute_frame_layout, at
config/i386/i386.c:9510
[]() noexcept { return __builtin_return_address(0); }();
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
g++ version:
E:\Desktop>g++ -v
Thread model: win32
gcc version 4.9.0 (i686-win32-sjlj-rev1, Built by MinGW-W64 project)
[Bug driver/61106] [4.8/4.9/4.10 Regression] impliedness of -Wunused-parameter depends on -W option ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61106 --- Comment #14 from Matthias Klose --- Author: doko Date: Wed May 14 16:18:12 2014 New Revision: 210432 URL: http://gcc.gnu.org/viewcvs?rev=210432&root=gcc&view=rev Log: gcc/ 2014-05-14 Matthias Klose Revert: 2014-05-08 Manuel López-Ibáñez Matthias Klose PR driver/61106 * optc-gen.awk: Fix option handling for -Wunused-parameter. gcc/testsuite/ 2014-05-14 Matthias Klose PR driver/61106 * gcc-dg/unused-8a.c: Remove. Removed: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/unused-8a.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/optc-gen.awk branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug driver/61106] [4.8/4.9/4.10 Regression] impliedness of -Wunused-parameter depends on -W option ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61106 --- Comment #15 from Matthias Klose --- Author: doko Date: Wed May 14 16:22:20 2014 New Revision: 210434 URL: http://gcc.gnu.org/viewcvs?rev=210434&root=gcc&view=rev Log: gcc/ 2014-05-14 Matthias Klose Revert: 2014-05-08 Manuel López-Ibáñez Matthias Klose PR driver/61106 * optc-gen.awk: Fix option handling for -Wunused-parameter. gcc/testsuite/ 2014-05-14 Matthias Klose PR driver/61106 * gcc-dg/unused-8a.c: Remove. Removed: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/unused-8a.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/optc-gen.awk branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug driver/61106] [4.8/4.9/4.10 Regression] impliedness of -Wunused-parameter depends on -W option ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61106 Matthias Klose changed: What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |--- --- Comment #16 from Matthias Klose --- reverted the change for the branches and removed the unused-8a.c testcase as requested by richi and jakub.
[Bug fortran/61126] [4.10 Regression] gfortran does not enable -Wununused-parameter with -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126 Matthias Klose changed: What|Removed |Added Summary|[4.8/4.9/4.10 Regression] |[4.10 Regression] gfortran |gfortran does not enable|does not enable |-Wununused-parameter with |-Wununused-parameter with |-Wextra |-Wextra --- Comment #20 from Matthias Klose --- the fix for PR61106 is now reverted on the branches.
[Bug ipa/61085] [4.9/4.10 Regression] wrong code with -O2 -fno-early-inlining (maybe wrong devirtualization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61085 Martin Jambor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org --- Comment #3 from Martin Jambor --- Mine
[Bug c++/20332] poor diagnostic when bind non lvalue to a reference for default arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20332 --- Comment #3 from Jason Merrill --- Author: jason Date: Wed May 14 16:48:07 2014 New Revision: 210436 URL: http://gcc.gnu.org/viewcvs?rev=210436&root=gcc&view=rev Log: PR c++/20332 PR c++/21631 * call.c (reference_binding): Treat lvalue/rvalue mismatch and dropped cv-quals as a bad conversion. (convert_like_real) [ck_ref_bind]: Explain them. (compare_ics): Check badness before stripping reference bindings. Handle comparing bad reference bindings. * typeck.c (comp_cv_qualification): Add overload that just takes integers. * cp-tree.h: Declare it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/diag2.C trunk/gcc/testsuite/g++.dg/diagnostic/ref1.C trunk/gcc/testsuite/g++.dg/diagnostic/ref2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/typeck.c trunk/gcc/testsuite/g++.dg/conversion/op4.C trunk/gcc/testsuite/g++.dg/cpp0x/overloadn.C trunk/gcc/testsuite/g++.dg/expr/cond9.C trunk/gcc/testsuite/g++.dg/init/synth2.C trunk/gcc/testsuite/g++.dg/lookup/two-stage4.C trunk/gcc/testsuite/g++.dg/overload/arg3.C trunk/gcc/testsuite/g++.dg/overload/conv-op1.C trunk/gcc/testsuite/g++.dg/overload/copy1.C trunk/gcc/testsuite/g++.dg/overload/volatile1.C trunk/gcc/testsuite/g++.dg/rtti/dyncast6.C trunk/gcc/testsuite/g++.dg/template/copy1.C trunk/gcc/testsuite/g++.old-deja/g++.benjamin/15800-1.C trunk/gcc/testsuite/g++.old-deja/g++.brendan/cvt3.C trunk/gcc/testsuite/g++.old-deja/g++.bugs/900514_03.C trunk/gcc/testsuite/g++.old-deja/g++.eh/ctor1.C trunk/gcc/testsuite/g++.old-deja/g++.jason/temporary2.C trunk/gcc/testsuite/g++.old-deja/g++.law/cvt20.C trunk/gcc/testsuite/g++.old-deja/g++.law/enum4.C trunk/gcc/testsuite/g++.old-deja/g++.law/init8.C trunk/gcc/testsuite/g++.old-deja/g++.law/operators9.C trunk/gcc/testsuite/g++.old-deja/g++.mike/net8.C trunk/gcc/testsuite/g++.old-deja/g++.mike/p1989.C trunk/gcc/testsuite/g++.old-deja/g++.mike/p2431.C trunk/gcc/testsuite/g++.old-deja/g++.mike/p438.C trunk/gcc/testsuite/g++.old-deja/g++.mike/p701.C trunk/gcc/testsuite/g++.old-deja/g++.other/crash24.C trunk/gcc/testsuite/g++.old-deja/g++.other/volatile1.C trunk/gcc/testsuite/g++.old-deja/g++.pt/auto_ptr.C trunk/gcc/testsuite/g++.old-deja/g++.pt/t05.C trunk/libstdc++-v3/testsuite/20_util/forward/1_neg.cc
[Bug c++/21631] diagnostic for a non constant reference when passed a non lvalue (copy constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21631 --- Comment #3 from Jason Merrill --- Author: jason Date: Wed May 14 16:48:07 2014 New Revision: 210436 URL: http://gcc.gnu.org/viewcvs?rev=210436&root=gcc&view=rev Log: PR c++/20332 PR c++/21631 * call.c (reference_binding): Treat lvalue/rvalue mismatch and dropped cv-quals as a bad conversion. (convert_like_real) [ck_ref_bind]: Explain them. (compare_ics): Check badness before stripping reference bindings. Handle comparing bad reference bindings. * typeck.c (comp_cv_qualification): Add overload that just takes integers. * cp-tree.h: Declare it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/diag2.C trunk/gcc/testsuite/g++.dg/diagnostic/ref1.C trunk/gcc/testsuite/g++.dg/diagnostic/ref2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/typeck.c trunk/gcc/testsuite/g++.dg/conversion/op4.C trunk/gcc/testsuite/g++.dg/cpp0x/overloadn.C trunk/gcc/testsuite/g++.dg/expr/cond9.C trunk/gcc/testsuite/g++.dg/init/synth2.C trunk/gcc/testsuite/g++.dg/lookup/two-stage4.C trunk/gcc/testsuite/g++.dg/overload/arg3.C trunk/gcc/testsuite/g++.dg/overload/conv-op1.C trunk/gcc/testsuite/g++.dg/overload/copy1.C trunk/gcc/testsuite/g++.dg/overload/volatile1.C trunk/gcc/testsuite/g++.dg/rtti/dyncast6.C trunk/gcc/testsuite/g++.dg/template/copy1.C trunk/gcc/testsuite/g++.old-deja/g++.benjamin/15800-1.C trunk/gcc/testsuite/g++.old-deja/g++.brendan/cvt3.C trunk/gcc/testsuite/g++.old-deja/g++.bugs/900514_03.C trunk/gcc/testsuite/g++.old-deja/g++.eh/ctor1.C trunk/gcc/testsuite/g++.old-deja/g++.jason/temporary2.C trunk/gcc/testsuite/g++.old-deja/g++.law/cvt20.C trunk/gcc/testsuite/g++.old-deja/g++.law/enum4.C trunk/gcc/testsuite/g++.old-deja/g++.law/init8.C trunk/gcc/testsuite/g++.old-deja/g++.law/operators9.C trunk/gcc/testsuite/g++.old-deja/g++.mike/net8.C trunk/gcc/testsuite/g++.old-deja/g++.mike/p1989.C trunk/gcc/testsuite/g++.old-deja/g++.mike/p2431.C trunk/gcc/testsuite/g++.old-deja/g++.mike/p438.C trunk/gcc/testsuite/g++.old-deja/g++.mike/p701.C trunk/gcc/testsuite/g++.old-deja/g++.other/crash24.C trunk/gcc/testsuite/g++.old-deja/g++.other/volatile1.C trunk/gcc/testsuite/g++.old-deja/g++.pt/auto_ptr.C trunk/gcc/testsuite/g++.old-deja/g++.pt/t05.C trunk/libstdc++-v3/testsuite/20_util/forward/1_neg.cc
[Bug libstdc++/61166] overflow when parse number in std::duration operator""
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61166 --- Comment #8 from Jonathan Wakely --- That's correct, and the standard is clear that operator""ms(unsigned long long) is required to return chrono::milliseconds, not some other equivalent duration with a different Rep. So I think the question in comment 4 is valid: why do we bother with these templates at all?
[Bug libstdc++/61166] overflow when parse number in std::duration operator""
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61166 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-14 Ever confirmed|0 |1
[Bug c++/20332] poor diagnostic when bind non lvalue to a reference for default arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20332 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #4 from Jason Merrill --- Fixed on trunk.
[Bug c++/21631] diagnostic for a non constant reference when passed a non lvalue (copy constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21631 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #4 from Jason Merrill --- Fixed on trunk.
[Bug c++/61182] [4.9/4.10 Regression] Forming pointer to qualified function type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182 --- Comment #11 from Daniel Krügler --- (In reply to pdaouadi from comment #3) > Still, if the standard says that it is not allowed we can work around it, > but then should I file a bug to clang? I have done so, http://llvm.org/bugs/show_bug.cgi?id=19742
[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969
Uroš Bizjak changed:
What|Removed |Added
Keywords||ra
Component|target |rtl-optimization
--- Comment #16 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #13)
> The matching pattern for:
>
> (insn 26 25 27 4 (set (reg:SF 147 [ D.2421 ])
> (float:SF (reg/v:SI 154 [ z ]))) 203 {*floatsisf2_i387}
> (expr_list:REG_DEAD (reg/v:SI 154 [ z ])
> (nil)))
>
> was removed by r208587. Without SSE math, MMX is used in *movsf_internal.
This has nothing to do with SSE math, but register preferences.
In i386.md, it is said for the above RTX that:
;; Even though we only accept memory inputs, the backend _really_
;; wants to be able to do this between registers. Thankfully, LRA
;; will fix this up for us during register allocation.
LRA fixes this in a wrong way and puts the value in %mm register, see also
comment #10.
Reconfirmed on mainline as RA problem using "-O2 -ftree-vectorize
-march=pentium4 -m32" with Jakub's test from Comment #1.
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #47 from Roland Schulz --- Using 4.9 and --disable-linux-futex I don't get any false positives. Thus the problem I saw with 4.8.2 is indeed fixed with 4.9. Thanks! What is the advantage of a TSAN instrumented libgomp over one with --disable-linux-futex?
[Bug debug/61013] [4.9/4.10 Regression] Option parsing difference between < 4.9 and 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 --- Comment #13 from Richard Henderson --- (In reply to ccoutant from comment #10) > Sorry, I'm not sure what "both points" are. Does that mean that you > would support changing -g so that -g1 -g means -g2, but -g3 -g means > -g3? (I.e., -g will raise the level to 2 but will not lower it.) Yes, that's what I meant.
[Bug libgcc/56846] _Unwind_Backtrace on ARM and noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846 --- Comment #4 from npl at chello dot at --- I just found the similar entry on launchpad. I have to recall this from memory, as its been a long time since I played around with it. The issue of repeating entries occurs if you have a function wihout stack-unwinding information. These are as far as I know: * .cantunwind in asm, probably plain asm too * "C compiled" compiled without flags to generate unwind tables * C++ compiled function with noexcept Further, the compiled code behaves right when exceptions are thrown (std::terminate), so the tables and generated code should be fine. The issue should thus be in libgcc`s implementation of the _Unwind_Backtrace function.
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #48 from Joost VandeVondele --- (In reply to Roland Schulz from comment #47) > What is the advantage of a TSAN instrumented libgomp over one with > --disable-linux-futex? I would be happy to know that '--disable-linux-futex' is a suitable approach, as that would be rather practical. However, my first idea would be that, since libgomp is not sanitized, not all races in 'user land' would be detected. I'm just guessing ...
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #49 from Dmitry Vyukov --- > However, my first idea would be that, since libgomp is not sanitized, not all > races in 'user land' would be detected. I'm just guessing ... If libgomp does not access user data (which I suspect it does not generally do), then un-instrumented libgomp can only lead to false positives due to missed synchronization in libgomp. The missed synchronization can come mostly from atomic operations, because tsan intercepts pthread_mutex and other library functions.
[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969 --- Comment #17 from H.J. Lu --- As long as both MMX and X87 registers are available to register allocator, they may be used at the same time even if MMX usage is disparaged. Can we disable MMX registers when x87 registers used on a per-function basis?
[Bug ipa/61190] New: [4.8/4.9/4.10 Regression] g++.old-deja/g++.mike/p4736b.C FAILs at -O2/-Os/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61190 Bug ID: 61190 Summary: [4.8/4.9/4.10 Regression] g++.old-deja/g++.mike/p4736b.C FAILs at -O2/-Os/-O3 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 32798 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32798&action=edit prep Valgrind output with various GCC versions: $ g++-trunk-r210412 -O2 p4736b.ii $ valgrind -q --track-origins=yes ./a.out ==11986== Use of uninitialised value of size 8 ==11986==at 0x4006F3: virtual thunk to Main::foo() (in /home/smatz/gcc-bug/1256/a.out) ==11986==by 0x400517: main (in /home/smatz/gcc-bug/1256/a.out) ==11986== Uninitialised value was created by a stack allocation ==11986==at 0x400500: main (in /home/smatz/gcc-bug/1256/a.out) ==11986== ==11986== Invalid read of size 8 ==11986==at 0x4006F3: virtual thunk to Main::foo() (in /home/smatz/gcc-bug/1256/a.out) ==11986==by 0x400517: main (in /home/smatz/gcc-bug/1256/a.out) ==11986== Address 0xffe8 is not stack'd, malloc'd or (recently) free'd ==11986== ==11986== ==11986== Process terminating with default action of signal 11 (SIGSEGV) ==11986== Access not within mapped region at address 0xFFE8 ==11986==at 0x4006F3: virtual thunk to Main::foo() (in /home/smatz/gcc-bug/1256/a.out) ==11986==by 0x400517: main (in /home/smatz/gcc-bug/1256/a.out) $ g++-4_9-r210307 -O2 p4736b.ii $ valgrind -q --track-origins=yes ./a.out ==12013== Use of uninitialised value of size 8 ==12013==at 0x4006F3: virtual thunk to Main::foo() (in /home/smatz/gcc-bug/1256/a.out) ==12013==by 0x400517: main (in /home/smatz/gcc-bug/1256/a.out) ==12013== Uninitialised value was created by a stack allocation ==12013==at 0x400500: main (in /home/smatz/gcc-bug/1256/a.out) ==12013== ==12013== Invalid read of size 8 ==12013==at 0x4006F3: virtual thunk to Main::foo() (in /home/smatz/gcc-bug/1256/a.out) ==12013==by 0x400517: main (in /home/smatz/gcc-bug/1256/a.out) ==12013== Address 0xffe8 is not stack'd, malloc'd or (recently) free'd ==12013== ==12013== ==12013== Process terminating with default action of signal 11 (SIGSEGV) ==12013== Access not within mapped region at address 0xFFE8 ==12013==at 0x4006F3: virtual thunk to Main::foo() (in /home/smatz/gcc-bug/1256/a.out) ==12013==by 0x400517: main (in /home/smatz/gcc-bug/1256/a.out) $ g++-4_8-r210303 -O2 p4736b.ii $ valgrind -q --track-origins=yes ./a.out ==12047== Use of uninitialised value of size 8 ==12047==at 0x4006C3: virtual thunk to Main::foo() (in /home/smatz/gcc-bug/1256/a.out) ==12047==by 0x400517: main (in /home/smatz/gcc-bug/1256/a.out) ==12047== Uninitialised value was created by a stack allocation ==12047==at 0x400500: main (in /home/smatz/gcc-bug/1256/a.out) ==12047== ==12047== Invalid read of size 8 ==12047==at 0x4006C3: virtual thunk to Main::foo() (in /home/smatz/gcc-bug/1256/a.out) ==12047==by 0x400517: main (in /home/smatz/gcc-bug/1256/a.out) ==12047== Address 0xffe8 is not stack'd, malloc'd or (recently) free'd ==12047== ==12047== ==12047== Process terminating with default action of signal 11 (SIGSEGV) ==12047== Access not within mapped region at address 0xFFE8 ==12047==at 0x4006C3: virtual thunk to Main::foo() (in /home/smatz/gcc-bug/1256/a.out) ==12047==by 0x400517: main (in /home/smatz/gcc-bug/1256/a.out) $ g++-4_7-r210302 -O2 p4736b.ii $ valgrind -q --track-origins=yes ./a.out ==12072== Use of uninitialised value of size 8 ==12072==at 0x4006C3: virtual thunk to Main::foo() (in /home/smatz/gcc-bug/1256/a.out) ==12072==by 0x400511: main (in /home/smatz/gcc-bug/1256/a.out) ==12072== Uninitialised value was created by a stack allocation ==12072==at 0x400500: main (in /home/smatz/gcc-bug/1256/a.out) ==12072== ==12072== Use of uninitialised value of size 8 ==12072==at 0x4006C3: virtual thunk to Main::foo() (in /home/smatz/gcc-bug/1256/a.out) ==12072==by 0x40052B: main (in /home/smatz/gcc-bug/1256/a.out) ==12072== Uninitialised value was created by a stack allocation ==12072==at 0x400500: main (in /home/smatz/gcc-bug/1256/a.out) ==12072== ==12072== Use of uninitialised value of size 8 ==12072==at 0x4006D7: virtual thunk to Main::foo() (in /home/smatz/gcc-bug/1256/a.out) ==12072==by 0x40053F: main (in /home/smatz/gcc-bug/1256/a.out) ==12072== Uninitialised value was created by a stack allocation ==12072==at 0x400500: main (in /home/smatz/gcc-bug/1256/a.out) ==12072== ==12072== Use of uninitialised value of size 8 ==12072==at 0x4006E7: virtual thunk to Main::foo() (in /home/smatz/gcc-bug/1256/a.out) ==12072==by 0x400553: main (in /home/smatz/gcc-bug/1256/a.out) ==120
[Bug rtl-optimization/60969] [4.9/4.10 Regression] ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969 --- Comment #18 from Richard Henderson --- (In reply to H.J. Lu from comment #17) That's probably the best solution long-term. Sometime before register allocation (but not too far before) inspect the insn stream and see what's left. If we see no mmx (explicit patterns, or asms using y constraint), disable the mmx registers entirely. If we see mmx, and we don't see modes that *require* 387 (i.e. SFmode present but 3dnow/sse1+ssemath enabled, or DFmode present but sse2+ssemath enabled), then disable the 387 registers entirely. If we've got a function that uses both mmx and 387... warn? I can't imagine that the RA would do anything nice. Really I'd love to be able to drop mmx support entirely. I'd be surprised if we couldn't emulate mmx builtins on sse2. And how many mmx-but-not-sse machines are really left alive?
[Bug libstdc++/58038] std::this_thread::sleep_until can cause inifinite sleep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58038 --- Comment #8 from Matthew Lai --- Here is another case where this bug caused a hard-to-find problem - http://stackoverflow.com/questions/17574287/boostthread-attributes-setting-call-stack-size (last comment) Since a patch is already available, is there an ETA for this bug to be fixed? I'd love to be able to take out my workaround in my program. Thanks!
[Bug lto/61001] Builtin memcpy and memset cannot be overridden when -flto is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61001 --- Comment #5 from Hans-Peter Nilsson --- Well, it sucks as a failure mode. (User: "*Multiple* definitions? But I provided *one*! Surely a linker bug/misfeature of some sorts!") (Note: I'd be totally ok with e.g. compiling memcpy into a recursive function, so the typical user may not agree!) Anyway I'm less and less convinced that this behavior is desired (forgetting about whatever functions happen to also be builtins when emitting the LTO tentative symbols, then *re-introducing* them when emitting the real object code). See also PR55994.
[Bug debug/61013] [4.9/4.10 Regression] Option parsing difference between < 4.9 and 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 --- Comment #14 from Cary Coutant --- Author: ccoutant Date: Wed May 14 21:48:47 2014 New Revision: 210442 URL: http://gcc.gnu.org/viewcvs?rev=210442&root=gcc&view=rev Log: Change -g so that it will override -g1 but not -g3. gcc/ PR debug/61013 * opts.c (common_handle_option): Don't special-case "-g". (set_debug_level): Default to at least level 2 with "-g". Modified: trunk/gcc/ChangeLog trunk/gcc/opts.c
[Bug target/57836] large constants evaluated inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57836 --- Comment #2 from David Edelsohn --- The affect of deligitimize_address on storing constants in the TOC vs materializing inline was unintentional, but my JIT experiments on POWER7 did not show a bad performance affect from materializing inline. Before we restore the old behavior, we should try to figure out which method actually produces better performance on recent hardware for PPC64 Linux and AIX.
[Bug debug/61013] [4.9/4.10 Regression] Option parsing difference between < 4.9 and 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 --- Comment #15 from Cary Coutant --- Author: ccoutant Date: Thu May 15 00:34:20 2014 New Revision: 210456 URL: http://gcc.gnu.org/viewcvs?rev=210456&root=gcc&view=rev Log: Change -g so that it will override -g1 but not -g3. Backported from trunk r210442. gcc/ PR debug/61013 * opts.c (common_handle_option): Don't special-case "-g". (set_debug_level): Default to at least level 2 with "-g". Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/opts.c
[Bug debug/61013] [4.9/4.10 Regression] Option parsing difference between < 4.9 and 4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013 Cary Coutant changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ccoutant at gcc dot gnu.org --- Comment #16 from Cary Coutant --- Fixed on trunk and on 4.9 branch.
[Bug libstdc++/60966] std::call_once sometime hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #14 from Hideaki Kimura ---
(In reply to Jonathan Wakely from comment #13)
> This means you are waiting on an object that has gone out of scope. WIthout
> more information it's not possible to tell if this is a bug in your program
> or the standard libary.
>
> I'll try to reproduce it with Thomas's code...
Hey Jonathan,
I'm not sure if this helps, but could you try the following code snippet?
#include
#include
#include
#include
struct DummyTask {
DummyTask(int id) : id_(id) {}
int id_;
std::promise pr;
};
const int THREADS = 100;
void run_task(DummyTask* task) {
std::this_thread::sleep_for(std::chrono::milliseconds(100));
task->pr.set_value();
}
void wait_for_task(DummyTask* task) {
task->pr.get_future().wait();
}
int main() {
std::vector tasks;
std::vector threads;
for (int i = 0; i < THREADS; ++i) {
DummyTask* task = new DummyTask(i);
tasks.push_back(task);
threads.push_back(new std::thread(run_task, task));
}
for (int i = 0; i < THREADS; ++i) {
wait_for_task(tasks[i]);
// Because we returned from wait_for_task for this task, run_task is
surely done.
// No one else is referring to the task. So, even before
threads[i]->join(),
// it should be safe to delete it now.
delete tasks[i]; // but here you get an invalid read!
}
for (int i = 0; i < THREADS; ++i) {
threads[i]->join();
delete threads[i];
}
return 0;
}
Run it a few times on valgrind. You will see what I got.
If you move threads[i]->join() to the line before delete tasks[i], you don't
get the issue.
[Assuming that I'm not terribly missing something..]
My bet is that std::promise puts something on thread-local, which causes some
issue when std::promise's destructor is called before the corresponding
thread's join() is called.
[Bug tree-optimization/60172] [4.9/4.10 Regression] ARM performance regression from trunk@207239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172 --- Comment #16 from Thomas Preud'homme --- Hi Richard, could you expand on what you said in comment #13? I don't see how reassoc could help cse here. From what I understood, reassoc tries to group per rank. In our case, we have (view of the source with loop unrolling): Arr_2_Par_Ref [Int_Loc] [Int_Loc] = Int_Loc; /* some stmts */ Arr_2_Par_Ref [Int_Loc+10] [Int_Loc] = Arr_1_Par_Ref [Int_Loc]; If I'm not mistaken, in the first case you'd have: Int_Loc * 4 Int_Loc * 100 Arr_2_Par_Ref that would be added together with several statements. However in the second case you'd have: Int_Loc * 4 Int_Loc * 100 1000 Arr_2_Par_Ref that would be added together with several statements. I don't see how could 1000 being added first or last, it seems to me that it's always going to be in an intermediate statement and thus not all redanduncy would be eliminated by CSE. Please let me know if my reasonning is flawed so that I can progress toward a solution.
[Bug fortran/60928] gfortran issue with allocatable components and OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60928 --- Comment #7 from Sean Santos --- Ah, right. Thinking about it again today, my comment 5 is very confused for several reasons, and I don't agree with it anymore. My original interpretation is the only one that makes sense to me again. Namely "subobject of a list item with the allocatable attribute refers" to: a) an allocatable component, of b) a variable listed in the private clause. In this case, OpenMP 4.0 is saying something very straightforward: do essentially the same thing for both thread private allocatable variables, and allocatable components of thread private variables.
