[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 --- Comment #23 from Hossein Talebi --- Thank you also for the great work and such a nice compiler. I should have actually noticed this a lot sooner but I was trying to keep my code compiling with gcc 4.8. > It is comments like the above that inspire me to invest my > time in gfortran. Thanks for your support. > >
[Bug libfortran/68867] numeric formatting problem in the fortran library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867 --- Comment #7 from Jerry DeLisle --- In the test case, I need to adjust the line; if (astring(2:2) /= '9') then to: if (astring(3:3) /= '9') then since the previous patch corrected a missing leading zero on the formatting. I will do so tomorrow.
[Bug libfortran/68867] numeric formatting problem in the fortran library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867 Jerry DeLisle changed: What|Removed |Added Status|WAITING |NEW --- Comment #6 from Jerry DeLisle --- I have confirmed that fmt_g0_7.f08 fails. It gets down to either xfailing the test or modifying it to work with the rounding and precision of the particular platform. I confirmed it on a Power7 platform.
[Bug libstdc++/68863] Regular expressions: Backreferences don't work in negative lookahead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68863 Tim Shen changed: What|Removed |Added CC||timshen at gcc dot gnu.org --- Comment #1 from Tim Shen --- I believe that it already gets fixed in my refactoring branch (https://github.com/innocentim/gcc/commits/master). It's waiting for review. I'm looking at the root cause to come up with a backport, if it's needed.
[Bug libfortran/68867] numeric formatting problem in the fortran library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #5 from Jerry DeLisle --- I will take this one. I will run some tests and see what I can find out on PowerPC, Looks like rounding is a different. Thanks for report.
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 --- Comment #28 from Alexander --- this one file should recompile with -O1 optimization
[Bug libstdc++/68869] map::insert(P&&) broken in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68869 --- Comment #3 from TC --- This was http://cplusplus.github.io/LWG/lwg-defects.html#2005. I don't think the S example breaks any rule in the pre-LWG2005 version, either. That version requires that "P shall be convertible to value type", and static_assert(std::is_convertible>::value, "!!"); doesn't fire.
[Bug libstdc++/68869] map::insert(P&&) broken in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68869 --- Comment #2 from Jonathan Wakely --- Hmm, maybe the change was already in C++14. I'll still look into what was intended, my memory is that it was just an editorial simplification.
[Bug libstdc++/68869] map::insert(P&&) broken in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68869 --- Comment #1 from Jonathan Wakely --- That's a recent edit to the draft, not yet part of the standard. I don't think it was meant to change any behaviour, so I don't consider this a bug in libstdc++ until I get some clarification whether this change is intended or not.
[Bug middle-end/68870] New: ICE on valid code at -O1, -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68870
Bug ID: 68870
Summary: ICE on valid code at -O1, -O2 and -O3 on
x86_64-linux-gnu
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The following code causes an ICE when compiled with the current gcc trunk at
-O1, -O2 and -O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It is a regression from 5.3.x.
It looks identical to PR 68570, which has been fixed.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151211 (experimental) [trunk revision 231553] (GCC)
$
$ gcc-trunk -O0 -c small.c
$ gcc-5.3 -O1 -c small.c
$
$ gcc-trunk -O1 -c small.c
small.c: In function ‘fn1’:
small.c:9:1: internal compiler error: Segmentation fault
fn1 ()
^~~
0xaf8b2f crash_signal
../../gcc-trunk/gcc/toplev.c:334
0xe56a14 gimple_truth_valued_p(tree_node*, tree_node* (*)(tree_node*))
/tmp/objdir/gcc/gimple-match.c:162
0xec4c49 gimple_simplify_NE_EXPR
/tmp/objdir/gcc/gimple-match.c:47934
0xe5c559 gimple_simplify
/tmp/objdir/gcc/gimple-match.c:52197
0xe5ef1d gimple_resimplify2(gimple**, code_helper*, tree_node*, tree_node**,
tree_node* (*)(tree_node*))
../../gcc-trunk/gcc/gimple-match-head.c:159
0xecb538 gimple_simplify(gimple*, code_helper*, tree_node**, gimple**,
tree_node* (*)(tree_node*), tree_node* (*)(tree_node*))
../../gcc-trunk/gcc/gimple-match-head.c:748
0xb3f90f cleanup_control_expr_graph
../../gcc-trunk/gcc/tree-cfgcleanup.c:101
0xb3f90f cleanup_control_flow_bb
../../gcc-trunk/gcc/tree-cfgcleanup.c:200
0xb40ecd cleanup_tree_cfg_1
../../gcc-trunk/gcc/tree-cfgcleanup.c:673
0xb40ecd cleanup_tree_cfg_noloop
../../gcc-trunk/gcc/tree-cfgcleanup.c:737
0xb40ecd cleanup_tree_cfg()
../../gcc-trunk/gcc/tree-cfgcleanup.c:788
0xa2cba4 execute_function_todo
../../gcc-trunk/gcc/passes.c:1911
0xa2d5fb execute_todo
../../gcc-trunk/gcc/passes.c:2010
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
int printf (const char *, ...);
int a, f, g;
char b, d;
short c;
static short e;
char
fn1 ()
{
for (; b; b++)
{
int h = 5;
for (a = 0; a < 1; a++)
{
for (d = 0; d < 1; d++)
for (c = 0; c < 1; c++)
for (; e >= 0;)
return 5;
if (f)
h = 0;
}
if (h)
printf ("%d", 0);
}
return g;
}
[Bug libstdc++/68869] New: map::insert(P&&) broken in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68869
Bug ID: 68869
Summary: map::insert(P&&) broken in some cases
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
According to the standard ([map.modifiers]),
template pair insert(P&& x);
is equivalent to return emplace(std::forward(x)), provided that
std::is_constructible::value is true.
The following code does not compile when insert() is used, but does compile
when emplace() is used. The same issue also affects multimap.
#include
#include
#include
#include
struct S {
operator std::pair() const && { return {}; }
};
static_assert(std::is_constructible, S&&>::value,
"!!");
static_assert(std::is_constructible,
int>, std::pair, int>&&>::value, "!!");
int main(){
std::map, int> m;
std::map m2;
m.insert(std::make_pair(std::make_unique(), 1)); // Error
m2.insert(S()); // Error
m.emplace(std::make_pair(std::make_unique(), 1)); // OK
m2.emplace(S()); // OK
}
[Bug c/68868] New: atomic_init emits an unnecessary fence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68868
Bug ID: 68868
Summary: atomic_init emits an unnecessary fence
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
This is similar but not the same as as bug 68622. The following test case that
uses atomic_init() and shows that while libstdc++ handles the C++ case
efficiently, C does not and emits an unnecessary fence:
#if __cplusplus
# include
using std::atomic_int;
using std::atomic_init;
#else
# include
#endif
typedef atomic_int AI;
void foo (AI *ai)
{
atomic_init (ai, 123);
}
Gcc (in C mode) emits the following with -O2 on x86_64:
foo:
movl$123, (%rdi)
mfence
ret
G++, on the other hand, and Clang in both modes, emit the following efficient
code at -O2:
_Z3fooPSt6atomicIiE:
movl$123, (%rdi)
ret
The C code is worse because the C header doesn't distinguish
initialization from assignment and implements the atomic_init() macro as plain
assignment:
#define atomic_init(PTR, VAL) \
do\
{ \
*(PTR) = (VAL); \
} \
while (0)
Defining atomic_init() as in the otherwise untested patch below gets rid of the
unnecessary fence:
--- ginclude/stdatomic.h(revision 231532)
+++ ginclude/stdatomic.h(working copy)
@@ -77,13 +77,13 @@
#define ATOMIC_VAR_INIT(VALUE) (VALUE)
-#define atomic_init(PTR, VAL) \
- do \
-{ \
- *(PTR) = (VAL); \
-} \
- while (0)
+/* Initialize an atomic object pointed to by PTR with VALUE. */
+#define atomic_init(PTR, VALUE) __extension__ ({ \
+ __typeof__ (VALUE) __tmp = (VALUE); \
+ __atomic_store ((PTR), &__tmp, __ATOMIC_RELAXED); \
+})
+
#define kill_dependency(Y) \
__extension__\
({ \
[Bug tree-optimization/68844] [6 regression] gcc.dg/tree-ssa/ssa-dom-thread-4.c fails since r228306
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68844 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jeffrey A. Law --- Expected output fixed on trunk.
[Bug tree-optimization/68844] [6 regression] gcc.dg/tree-ssa/ssa-dom-thread-4.c fails since r228306
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68844 --- Comment #3 from Jeffrey A. Law --- Author: law Date: Fri Dec 11 23:18:22 2015 New Revision: 231577 URL: https://gcc.gnu.org/viewcvs?rev=231577&root=gcc&view=rev Log: [PATCH][PR tree-optimization/68844] Fix testcase expected output PR tree-optimization/68844 * gcc.dg/tree-ssa/ssa-dom-thread-4.c: Update expected output. 2015-12-11 Jan Beulich Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-4.c
[Bug libfortran/68867] numeric formatting problem in the fortran library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867 --- Comment #4 from William Seurer --- Removing the comment gives: 3 39 0.6919E-0001 Program aborted. Backtrace: Aborted (core dumped) It's been failing for at least a week; that's when I first noticed it. I'm running on power8 little endian though it also fails on big endian. gfortran -v: Using built-in specs. COLLECT_GCC=/home/seurer/gcc/build/gcc-test/gcc/testsuite/gfortran7/../../gfortran Target: powerpc64le-unknown-linux-gnu Configured with: ... Thread model: posix gcc version 6.0.0 20151211 (experimental) [trunk revision 231573] (GCC)
[Bug libstdc++/50703] std::stringstream not thread-safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50703 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #9 from Jonathan Wakely --- No testcase or results for supported releases provided, closing.
[Bug libstdc++/53477] pretty printer fails with: Python Exception list index out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #26 from Jonathan Wakely --- Feedback not forthcoming, closing.
[Bug libstdc++/56861] std::vector::reserve optimization bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56861
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1 |0
--- Comment #3 from Jonathan Wakely ---
This is the testcase, without the Boost dependency. Compile with -std=c++11.
Define RESERVE or RESERVE_PLUS_ONE to change the behaviour.
I can't reproduce any significant difference in performance using 4.7.4 or
trunk. The time is surely bound by the std::find_if calls and I/O on the file
(which fails unless the file already exists btw, because you use std::fstream
not std::ofstream).
I don't see any bug here, or anything that needs fixing.
#include
#include
#include
#include
#include
#include
#include
#include
#include
namespace {
constexpr size_t array_size = 1;
unsigned number() {
static std::random_device rd;
static std::mt19937 random_engine(rd());
static std::uniform_int_distribution distribution(0,
std::numeric_limits::max());
return distribution(random_engine);
}
class Class {
public:
Class() {
x[0] = number();
}
std::string to_string() const {
return std::to_string(x[0]);
}
inline friend bool operator<=(Class const & lhs, Class const &
rhs) {
return lhs.x[0] <= rhs.x[0];
}
private:
std::array x;
};
template
void add(Container & container, Class const & value) {
auto const it = std::find_if(std::begin(container),
std::end(container), [&](Class const & c) {
return value <= c;
});
container.emplace(it, value);
}
// Do something with the result
template
void insert_to_file(Container const & container) {
std::fstream file("file.txt");
for (auto const & value : container) {
file << value.to_string() << '\n';
}
}
template
void f(std::vector const & values) {
Container container;
#if defined RESERVE
container.reserve(values.size());
#elif defined RESERVE_PLUS_ONE
container.reserve(values.size() + 1);
#endif
for (auto const & value : values) {
add(container, value);
}
insert_to_file(container);
}
}
int main(int argc, char ** argv) {
std::size_t const size = (argc == 1) ? 1 : std::stoul(argv[1]);
// Default constructor of Class fills in values here
std::vector const values_to_be_copied(size);
typedef std::vector Container;
auto start = std::chrono::system_clock::now();
f(values_to_be_copied);
auto finish = std::chrono::system_clock::now();
std::cerr << "Finished in " <<
std::chrono::duration_cast>(finish -
start).count() << " seconds.\n";
}
[Bug libfortran/68867] numeric formatting problem in the fortran library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #3 from Bill Schmidt --- (In reply to kargl from comment #2) > > This is probably related to > > 2015-11-22 Jerry DeLisle > > * io/write_float.def (output_float): Move block determining > room for leading zero to before checkng g0 formatting. > > but William did not define "has been failing for a while now". I can confirm that this began failing with r230728, which is Jerry's patch.
[Bug libfortran/68867] numeric formatting problem in the fortran library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > Which platform are you using (gfortran -v)? > > What is the output if you uncomment the line > > !print *, i, l, trim(astring) > > ? This is probably related to 2015-11-22 Jerry DeLisle * io/write_float.def (output_float): Move block determining room for leading zero to before checkng g0 formatting. but William did not define "has been failing for a while now".
[Bug lto/68799] lto ICE on powerpc64le-linux-gnu builing python 2.7.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799 Bill Schmidt changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-11 Ever confirmed|0 |1 --- Comment #4 from Bill Schmidt --- Confirmed while building in doko's environment. However, I haven't been able to fully sort out the problem by looking at the SLSR detail dumps. It appears to involve two conditional candidates that depend on the same PHI basis. The first one is processed correctly, introducing a new PHI basis for it, but when we look at the second one it appears that we can no longer map from the PHI statement to the PHI candidate. It may have to do with using split_edge to place the add statements that feed the new PHI basis, but off the cuff I don't see anything wrong with that. Matthias, can you please incorporate th3 debug patch from the previous comment into your source so I can gather more information at the time of the failure? It won't change behavior of the compiler unless -fdump-tree-slsr* is specified.
[Bug lto/68799] lto ICE on powerpc64le-linux-gnu builing python 2.7.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68799 --- Comment #3 from Bill Schmidt --- Created attachment 37008 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37008&action=edit test patch to gather more information
[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 --- Comment #22 from kargl at gcc dot gnu.org --- (In reply to Hossein Talebi from comment #20) > I just submitted a new bug. It is a pity that my code cannot be compiled > with gfortran 4.9 and above for more than a year now.. It is comments like the above that inspire me to invest my time in gfortran. Thanks for your support.
[Bug libfortran/68867] numeric formatting problem in the fortran library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-11 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Which platform are you using (gfortran -v)? What is the output if you uncomment the line !print *, i, l, trim(astring) ?
[Bug libstdc++/67116] incorrect detection of thread model when cross-compiling the tool chain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67116 --- Comment #8 from Jonathan Wakely --- Yes, this would happen if you're setting CC and CXX, causing libstdc++ to be configured using the compiler specified by those variables, not the one that has just been built. So I think this is user error.
[Bug tree-optimization/68844] [6 regression] gcc.dg/tree-ssa/ssa-dom-thread-4.c fails since r228306
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68844 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-11 Ever confirmed|0 |1 --- Comment #2 from Jeffrey A. Law --- So there's 4 potential jump threads as we enter the first DOM pass. Before the change in question, all 4 would be threaded. After the change, we record just two threads and only actually realize one jump thread. So what happened? One of the two recorded jump threads is explicitly dropped. The block in question originally looks like: : # kill_elt_40 = PHI if (b_elt_10(D) != 0B) goto ; else goto ; We record a jump thread (7,18); (18,10) as exit block #7. We later proceed to optimize block 18 to look like: # kill_elt_40 = PHI goto ; (ie, along every path we know that b_elt_10 != 0B) So we remove the recorded jump thread (7,18); (18,10) -- this is desired behaviour. So the recorded, but unrealized jump thread is easily explained. Additionally, by optimizing block #18 like that, we find there's no need to record the jump thread (5,18); (18,10). Again, desired behaviour. We have a similar situation arise in another block: : if (b_elt_10(D) != 0B) goto ; else goto ; We optimize bb8 to look like: : goto ; Which eliminates the need for the jump thread (15,3); (3,8)J; (8,14). Very desirable behaviour as well. So of the 4 potential jump threads, only 1 is actually still relevant after the change in question. And it is properly threaded ;-) So everything is doing exactly what it should and we just need to twiddle the testcase a bit to reflect current reality.
[Bug libfortran/68867] New: numeric formatting problem in the fortran library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68867 Bug ID: 68867 Summary: numeric formatting problem in the fortran library Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- There is a problem in the formatting code in the fortran library. The test case fmt_g0_7.f8 has been failing for a while now and while investigating it I realized that it only fails when using the fortran library built with gcc trunk but works when I use the library from gcc 5.1 or earlier versions. I don't know fortran so it could be that the library is correct and the test case is wrong. seurer@genoa:~/gcc/build/gcc-test/gcc/testsuite$ export LD_LIBRARY_PATH=/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs seurer@genoa:~/gcc/build/gcc-test/gcc/testsuite$ ./fmt_g0_7.exe Program aborted. Backtrace: Aborted (core dumped) seurer@genoa:~/gcc/build/gcc-test/gcc/testsuite$ unset LD_LIBRARY_PATH seurer@genoa:~/gcc/build/gcc-test/gcc/testsuite$ ./fmt_g0_7.exe seurer@genoa:~/gcc/build/gcc-test/gcc/testsuite$ The abort comes from line 30 of the test case if (n /= 0) call abort If I run the code via gdb using the 6.0 library: Breakpoint 1, testit () at /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/fmt_g0_7.f08:14 14write(astring, '(ru,g0)') 1.0/real(10.0, kind=j(1)) (gdb) n 22 if (astring(2:2) /= '9') then (gdb) print astring $1 = '0.10002', ' ' But I see this when using an earlier library: Breakpoint 1, testit () at /home/seurer/gcc/gcc-test/gcc/testsuite/gfortran.dg/fmt_g0_7.f08:14 14write(astring, '(ru,g0)') 1.0/real(10.0, kind=j(1)) (gdb) n 22 if (astring(2:2) /= '9') then (gdb) print astring $1 = '.10002', ' ' Note the difference in the format of the decimal number. All 4 tests that the code does differ similarly and one of the differences triggers the call to abort.
[Bug target/68865] [6 regression] gcc.dg/atomic/c11-atomic-exec-2.c fails since r231165
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68865 --- Comment #2 from Bill Schmidt --- That's very possible. No doubt r231165 just caused it to come out of the woodwork again. However, I verified that it didn't ICE with r230600 - r231164, so something about r231165 managed to trigger the issue. Thanks for looking at it!
[Bug libstdc++/67116] incorrect detection of thread model when cross-compiling the tool chain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67116 --- Comment #7 from Jonathan Wakely --- The thread model is determined using: target_thread_file=`$CXX -v 2>&1 | sed -n 's/^Thread model: //p'` where $CXX is *supposed* to be the newly-built GCC, e.g. for my native builds the value of CXX is /home/jwakely/src/gcc/build/./gcc/xgcc -shared-libgcc -B/home/jwakely/src/gcc/build/./gcc -nostdinc++ -L/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/jwakely/gcc/6/x86_64-pc-linux-gnu/bin/ -B/home/jwakely/gcc/6/x86_64-pc-linux-gnu/lib/ -isystem /home/jwakely/gcc/6/x86_64-pc-linux-gnu/include -isystem /home/jwakely/gcc/6/x86_64-pc-linux-gnu/sys-include For a mingw64 cross I see /tmp/67116/./gcc/xgcc being used, so I don't know why your config.log shows x86_64-w64-mingw32-c++ being used. Are you setting CXX or doing anything funny in the libstdc++ build dir?
[Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564
--- Comment #21 from H.J. Lu ---
This bug isn't fixed in GCC 4.9. -O3 increases alignment from
64 bits to 128 bits on the original testcase:
Hardware watchpoint 6: *(unsigned int *) 0x7fffee9b4468
Old value = 64
New value = 128
ensure_base_align (stmt_info=0x1c8f990, dr=0x1db5b20)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-stmts.c:4907
4907 DECL_USER_ALIGN (base_decl) = 1;
(gdb) bt
#0 ensure_base_align (stmt_info=0x1c8f990, dr=0x1db5b20)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-stmts.c:4907
#1 0x00d33471 in vectorizable_store (stmt=0x7fffed95a280,
gsi=0x7fffd830, vec_stmt=0x7fffd790, slp_node=0x1d9e7a0)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-stmts.c:5131
#2 0x00d38f80 in vect_transform_stmt (stmt=0x7fffed95a280,
gsi=0x7fffd830, grouped_store=0x7fffd84a, slp_node=0x1d9e7a0,
slp_node_instance=0x1cb3e10)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-stmts.c:7211
#3 0x00d5a980 in vect_schedule_slp_instance (node=0x1d9e7a0,
instance=0x1cb3e10, vectorization_factor=1)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-slp.c:3084
#4 0x00d5abd0 in vect_schedule_slp (loop_vinfo=0x0,
bb_vinfo=0x1ddf410)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-slp.c:3154
#5 0x00d5aea7 in vect_slp_transform_bb (bb=0x7fffece8ec30)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-slp.c:3230
#6 0x00d5e41b in execute_vect_slp ()
at /export/gnu/import/git/gcc-release/gcc/tree-vectorizer.c:605
#7 0x00d5e4c9 in (anonymous namespace)::pass_slp_vectorize::execute (
this=0x1b97010)
at /export/gnu/import/git/gcc-release/gcc/tree-vectorizer.c:649
#8 0x00a7da14 in execute_one_pass (pass=0x1b97010)
---Type to continue, or q to quit---q
at /export/gnu/imporQuit
(gdb) f 1
#1 0x00d33471 in vectorizable_store (stmt=0x7fffed95a280,
gsi=0x7fffd830, vec_stmt=0x7fffd790, slp_node=0x1d9e7a0)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-stmts.c:5131
5131 ensure_base_align (stmt_info, dr);
(gdb) f 2
#2 0x00d38f80 in vect_transform_stmt (stmt=0x7fffed95a280,
gsi=0x7fffd830, grouped_store=0x7fffd84a, slp_node=0x1d9e7a0,
slp_node_instance=0x1cb3e10)
at /export/gnu/import/git/gcc-release/gcc/tree-vect-stmts.c:7211
7211 done = vectorizable_store (stmt, gsi, &vec_stmt, slp_node);
(gdb)
This bug may be really fixed by r221268:
iff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index aa9d43f..41ff802 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -4956,8 +4956,13 @@ ensure_base_align (stmt_vec_info stmt_info, struct
data_reference *dr)
tree vectype = STMT_VINFO_VECTYPE (stmt_info);
tree base_decl = ((dataref_aux *)dr->aux)->base_decl;
- DECL_ALIGN (base_decl) = TYPE_ALIGN (vectype);
- DECL_USER_ALIGN (base_decl) = 1;
+ if (decl_in_symtab_p (base_decl))
+ symtab_node::get (base_decl)->increase_alignment (TYPE_ALIGN (vectype));
+ else
+ {
+ DECL_ALIGN (base_decl) = TYPE_ALIGN (vectype);
+ DECL_USER_ALIGN (base_decl) = 1;
+ }
((dataref_aux *)dr->aux)->base_misaligned = false;
}
}
in GCC 5.
[Bug libstdc++/61617] add boost::coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61617 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jonathan Wakely --- Closing, this isn't something we want to add until it comes through the standardisation process, and it doesn't look like Boost.Coroutine is the direction the committee is going.
[Bug libstdc++/63617] Crash in libstdc++ on AIX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63617 --- Comment #3 from Jonathan Wakely --- The currently supported releases are shown on https://gcc.gnu.org/ At any time there are two supported releases series, currently 4.9.x and 5.x, which changes annually when the new release happens (GCC 6 is due around April). Without the information requested by https://gcc.gnu.org/bugs/ and using a supported release this bug report will probably be closed.
[Bug fortran/46496] Missing strlen check / interop warnings with BIND(C) and non-C_* kinds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46496 Dominique d'Humieres changed: What|Removed |Added CC||valeryweber at hotmail dot com --- Comment #3 from Dominique d'Humieres --- *** Bug 68856 has been marked as a duplicate of this bug. ***
[Bug fortran/68856] wrong compilation wtih character interoperability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68856 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres --- Duplicate of pr46496 item (f) in comment 0. *** This bug has been marked as a duplicate of bug 46496 ***
[Bug target/68865] [6 regression] gcc.dg/atomic/c11-atomic-exec-2.c fails since r231165
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68865
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-12-11
Ever confirmed|0 |1
--- Comment #1 from Segher Boessenkool ---
It used to ICE before this patch. It has for a long time.
This isn't the patch you are looking for.
I'll take a look though, sure. Simplified testcase:
===
static void __attribute__ ((noinline))
testit (void)
{
static volatile _Atomic unsigned int a = (unsigned int) (-70);
if ((a /= (-10)) != (unsigned int) ((unsigned int) (-70) / (-10)))
abort ();
}
int
main (void)
{
testit ();
exit (0);
}
===
(compile with -O2 -latomic).
[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 --- Comment #21 from Dominique d'Humieres --- > I just submitted a new bug. It is a pity that my code cannot be compiled > with gfortran 4.9 and above for more than a year now.. (Part of) your code should compile with the 5.3.0 release.
[Bug fortran/68864] [6 Regression] ICE: in gfc_get_descriptor_dimension, at fortran/trans-array.c:268
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68864 Dominique d'Humieres changed: What|Removed |Added Summary|bug 61819 is not completely |[6 Regression] ICE: in |fixed |gfc_get_descriptor_dimensio ||n, at ||fortran/trans-array.c:268 --- Comment #2 from Dominique d'Humieres --- > The code compiles with 5.3.0 and 5.3.1 (r231560). With trunk it compiles > with r229303 (2015-10-25), r229438 gives the ICE Hence a regression.
[Bug fortran/68864] bug 61819 is not completely fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68864 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-11 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- The code compiles with 5.3.0 and 5.3.1 (r231560). With trunk it compiles with r229303 (2015-10-25), r229438 gives the ICE pr68864.f90:23:0: End Module part_base2_class 1 internal compiler error: in gfc_get_descriptor_dimension, at fortran/trans-array.c:272 up to r231573.
[Bug libstdc++/67116] incorrect detection of thread model when cross-compiling the tool chain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67116 Jonathan Wakely changed: What|Removed |Added Status|WAITING |NEW
[Bug middle-end/68215] [6 regression] FAIL: c-c++-common/opaque-vector.c -std=c++11 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68215 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Eric Botcazou --- .
[Bug middle-end/68215] [6 regression] FAIL: c-c++-common/opaque-vector.c -std=c++11 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68215 --- Comment #3 from Eric Botcazou --- Author: ebotcazou Date: Fri Dec 11 21:58:48 2015 New Revision: 231575 URL: https://gcc.gnu.org/viewcvs?rev=231575&root=gcc&view=rev Log: PR middle-end/68215 * tree-vect-generic.c (tree_vec_extract): Remove GSI parameter. Do not gimplify the result. (do_unop): Adjust call to tree_vec_extract. (do_binop): Likewise. (do_compare): Likewise. (do_plus_minus): Likewise. (do_negate): Likewise. (expand_vector_condition): Likewise. (do_cond): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-generic.c
[Bug libstdc++/41628] _GLIBCXX_DEBUG feature: check for unstable iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41628 --- Comment #4 from Jonathan Wakely --- Roland, could you please clarify the request, or I'll close this report as WORKSFORME. What do you mean by "unstable iterator" and what is the problem you want to solve?
[Bug libstdc++/59768] [DR 2219] std::thread constructor not handling reference_wrapper correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59768 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #5 from Jonathan Wakely --- Fixed on trunk.
[Bug libstdc++/59768] [DR 2219] std::thread constructor not handling reference_wrapper correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59768 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Fri Dec 11 21:45:51 2015 New Revision: 231574 URL: https://gcc.gnu.org/viewcvs?rev=231574&root=gcc&view=rev Log: Fix std::invoke support for reference_wrappers PR libstdc++/59768 * include/std/functional (_Unwrap, __invfwd): Define. (__invoke_impl): Remove reference_wrapper overloads and use __invfwd. * include/std/type_traits (__result_of_memobj, __result_of_memfun): Add partial specializations for const reference_wrappers and simplify. * testsuite/20_util/bind/ref_neg.cc: Use dg-excess-errors. * testsuite/20_util/function_objects/invoke/59768.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/function_objects/invoke/ trunk/libstdc++-v3/testsuite/20_util/function_objects/invoke/59768.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/functional trunk/libstdc++-v3/include/std/type_traits trunk/libstdc++-v3/testsuite/20_util/bind/ref_neg.cc
[Bug c/68866] New: ICE in set_lattice_value, at tree-ssa-cpp.c:490
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68866
Bug ID: 68866
Summary: ICE in set_lattice_value, at tree-ssa-cpp.c:490
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: felix.janda at posteo dot de
Target Milestone: ---
Minimal test case (containing invalid code):
static char *a[] = {""};
int main(void) {
for(int i=1;i<2;i++) if(a[i]) break;
}
The same error was already observed in
http://www.openwall.com/lists/musl/2013/11/07/14
[Bug target/68865] [6 regression] gcc.dg/atomic/c11-atomic-exec-2.c fails since r231165
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68865 Bill Schmidt changed: What|Removed |Added Target Milestone|--- |6.0
[Bug target/68865] New: [6 regression] gcc.dg/atomic/c11-atomic-exec-2.c fails since r231165
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68865 Bug ID: 68865 Summary: [6 regression] gcc.dg/atomic/c11-atomic-exec-2.c fails since r231165 Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: wschmidt at gcc dot gnu.org CC: dje.gcc at gmail dot com, segher at gcc dot gnu.org, seurer at linux dot vnet.ibm.com Target Milestone: --- Host: powerpc64*-*-linux* Target: powerpc64*-*-linux* Build: powerpc64*-*-linux* The subject test case fails as follows on Power: FAIL: gcc.dg/atomic/c11-atomic-exec-2.c -O2 execution test FAIL: gcc.dg/atomic/c11-atomic-exec-2.c -O2 -flto -fno-use-linker-plugin -fl\ to-partition=none execution test FAIL: gcc.dg/atomic/c11-atomic-exec-2.c -O2 -flto -fuse-linker-plugin -fno-f\ at-lto-objects execution test FAIL: gcc.dg/atomic/c11-atomic-exec-2.c -O3 -fomit-frame-pointer -funroll-lo\ ops -fpeel-loops -ftracer -finline-functions execution test FAIL: gcc.dg/atomic/c11-atomic-exec-2.c -O3 -g execution test FAIL: gcc.dg/atomic/c11-atomic-exec-2.c -Os execution test The regression occurred starting with r231165, which is: 2015-12-02 Segher Boessenkool * config/rs6000/rs6000.md (cstore_si_as_di): New expander. (cstore4): Use it. Segher, could you please investigate?
[Bug c++/68847] [6 Regression] ICE in cxx_eval_constant_expression on __atomic_compare_exchange (constexpr.c:3719) in c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68847 --- Comment #2 from Markus Trippelsdorf --- Whoops pasted to the wrong bug. Please ignore.
[Bug ipa/68851] [6 Regression] ICE: in set_comdat_group, at ipa-comdats.c:213
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68851
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-12-11
Ever confirmed|0 |1
--- Comment #6 from Markus Trippelsdorf ---
class A;
class B {
public:
operator A *() const;
};
class A {
public:
virtual bool isFormControlElement() const {}
};
class C {
struct D {
B element;
};
bool checkPseudoClass(const D &, int &) const;
};
class F {
virtual bool isFormControlElement() const;
};
class G : A, F {
bool isFormControlElement() const {}
};
bool C::checkPseudoClass(const D &p1, int &) const {
A &a = *p1.element;
a.isFormControlElement();
a.isFormControlElement() || a.isFormControlElement();
}
[Bug c++/68847] [6 Regression] ICE in cxx_eval_constant_expression on __atomic_compare_exchange (constexpr.c:3719) in c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68847
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-12-11
CC||trippels at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf ---
class A;
class B {
public:
operator A *() const;
};
class A {
public:
virtual bool isFormControlElement() const {}
};
class C {
struct D {
B element;
};
bool checkPseudoClass(const D &, int &) const;
};
class F {
virtual bool isFormControlElement() const;
};
class G : A, F {
bool isFormControlElement() const {}
};
bool C::checkPseudoClass(const D &p1, int &) const {
A &a = *p1.element;
a.isFormControlElement();
a.isFormControlElement() || a.isFormControlElement();
}
[Bug target/68543] [AArch64] Implement overflow arithmetic standard names {u,}{add,sub,mul}v4 and/or negv3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68543 --- Comment #4 from Michael Collison --- Okay thanks. After looking into the topic I did not see the direct connection either. On 12/11/2015 7:21 AM, ktkachov at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68543 > > --- Comment #3 from ktkachov at gcc dot gnu.org --- > After some discussion on IRC, WORD_REGISTER_OPERATIONS seems wrong for aarch64 > since 32-bit operations i.e. in SImode operate like normal 32-bit operations > because they use the 32-bit W-form of the registers. Thus they don't behave > like word_mode operations, because word_mode is DImode on aarch64. > So we may want to look at implementing the standard names after all >
[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 --- Comment #20 from Hossein Talebi --- I just submitted a new bug. It is a pity that my code cannot be compiled with gfortran 4.9 and above for more than a year now.. On Fri, Dec 11, 2015 at 9:01 PM, kargl at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 > > --- Comment #19 from kargl at gcc dot gnu.org --- > (In reply to Hossein Talebi from comment #18) > > I am now trying this bug and the Bug 68415 with the new GCC from trunc > and > > it is fine. Nevertheless, this other code does not compile. > > (gcc version 6.0.0 20151129 (experimental)) > > > > Please open a new bug report. Add a comment with code > exhibiting a bug to a CLOSED bug report is a good way > to get the report ignored. > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
[Bug fortran/68864] New: bug 61819 is not completely fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68864 Bug ID: 68864 Summary: bug 61819 is not completely fixed Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: talebi.hossein at gmail dot com Target Milestone: --- I am now trying bug 61819 and the Bug 68415 with the new GCC from trunk and it is fine. Nevertheless, this other code does not compile. (gcc version 6.0.0 20151129 (experimental)) Module part_base2_class implicit none type :: ty_moc1 integer l end type ty_moc1 integer,parameter :: MAX_NUM_ELEMENT_TYPE=32 type :: ty_element_index2 class(ty_moc1),allocatable :: element class(ty_moc1),allocatable :: element_th(:) endtype ty_element_index2 type :: ty_part_base2 type(ty_element_index2)::element_index(MAX_NUM_ELEMENT_TYPE) end type ty_part_base2 class(ty_part_base2),allocatable :: part_tmp_obj End Module part_base2_class
[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 --- Comment #19 from kargl at gcc dot gnu.org --- (In reply to Hossein Talebi from comment #18) > I am now trying this bug and the Bug 68415 with the new GCC from trunc and > it is fine. Nevertheless, this other code does not compile. > (gcc version 6.0.0 20151129 (experimental)) > Please open a new bug report. Add a comment with code exhibiting a bug to a CLOSED bug report is a good way to get the report ignored.
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 --- Comment #27 from The Written Word --- (In reply to John Buddery from comment #24) > You can use --disable-libgomp in the configure command, I had to do this on > my HP builds. I rebuilt without --disable-libgomp and get: /opt/build/gcc-4.8.5/libcpp/charset.c: In function 'cset_converter init_iconv_desc(cpp_reader*, const char*, const char*)': /opt/build/gcc-4.8.5/libcpp/charset.c:691:1: internal compiler error: in plus_constant, at explow.c:86 } ^ Maybe 4.9 is different.
[Bug fortran/61819] [4.9/4.10 Regression] ICE in gfc_conv_descriptor_data_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61819 --- Comment #18 from Hossein Talebi --- I am now trying this bug and the Bug 68415 with the new GCC from trunc and it is fine. Nevertheless, this other code does not compile. (gcc version 6.0.0 20151129 (experimental)) Module part_base2_class implicit none type :: ty_moc1 integer l end type ty_moc1 integer,parameter :: MAX_NUM_ELEMENT_TYPE=32 type :: ty_element_index2 class(ty_moc1),allocatable :: element class(ty_moc1),allocatable :: element_th(:) endtype ty_element_index2 type :: ty_part_base2 type(ty_element_index2)::element_index(MAX_NUM_ELEMENT_TYPE) end type ty_part_base2 class(ty_part_base2),allocatable :: part_tmp_obj End Module part_base2_class
[Bug libstdc++/68863] New: Regular expressions: Backreferences don't work in negative lookahead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68863
Bug ID: 68863
Summary: Regular expressions: Backreferences don't work in
negative lookahead
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: allthecoolkidshaveone at gmail dot com
Target Milestone: ---
The following snippet should print out 'false' (And does on perl, javascript,
Microsoft's C++ compiler and everything else I tested on) but instead prints
out 'true' with g++/libstdc++.
#include
#include
int main(void) {
std::cout.setf(std::ios_base::boolalpha);
std::cout << std::regex_match("aa", std::regex("(.)(?!\\1).")) << '\n';
return 0;
}
It appears that backreferences aren't used in lookaheads in the libstdc++ regex
implementation like they should be?
[Bug debug/68848] allow -fdebug-prefix-map to read OLD prefix from environment (improve reproducibility)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68848 --- Comment #5 from Daniel Kahn Gillmor --- Created attachment 37007 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37007&action=edit ignore -fdebug-prefix-map when generating DW_AT_producer Here is an alternate approach (suggested by Bernd Schmidt): just avoid writing -fdebug-prefix-map to the DW_AT_producer field entirely.
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 --- Comment #26 from The Written Word --- (In reply to Alexander from comment #25) > ../gcc-4.8.5/configure \ > --enable-languages=c,c++ > --prefix=/import/home/nskdvlp/CC_Libs/CC/ia64-hp-hpux_11.31_-64 \ > --with-local-prefix=/usr/CC/ia64-hp-hpux_11.31_-64 --with-gnu-as \ > --with-as=/usr/local/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld \ > --disable-nls --disable-libgcj --enable-shared --enable-threads=posix > --with-dwarf2 \ > --disable-libgomp SED=/usr/local/bin/sed SHELL=/usr/bin/bash --enable-lto > > is my configure cmd line (but libs inlace in tree) What does the Runpath look like for your resulting binaries? Does it have the build prefix embedded?
[Bug libstdc++/59768] [DR 2219] std::thread constructor not handling reference_wrapper correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59768 Jonathan Wakely changed: What|Removed |Added Status|SUSPENDED |ASSIGNED --- Comment #3 from Jonathan Wakely --- 2219 is in the working paper now, but this example still doesn't compile, because I'm not very good at C++. Fix coming up ...
[Bug tree-optimization/68853] [6 Regression] gcc-6 miscompiles Chromium v8 garbage collector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68853 --- Comment #9 from Markus Trippelsdorf --- Thanks Andrew. Turned out the issue from comment 2 is similar. Both issues are solved with -fno-delete-null-pointer-checks. Maybe the chromium devs should add that flag to their default gcc flags...
[Bug tree-optimization/68862] [6 Regression] g++.dg/torture/pr59163.C FAILs with -flive-range-shrinkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68862 --- Comment #1 from Zdenek Sojka --- Created attachment 37006 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37006&action=edit reduced testcase
[Bug tree-optimization/68862] New: [6 Regression] g++.dg/torture/pr59163.C FAILs with -flive-range-shrinkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68862 Bug ID: 68862 Summary: [6 Regression] g++.dg/torture/pr59163.C FAILs with -flive-range-shrinkage Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Compiler output: $ gcc testcase.c -O3 -flive-range-shrinkage $ ./a.out Segmentation fault (gdb) disassemble Dump of assembler code for function foo: 0x00400540 <+0>: movaps 0x89(%rip),%xmm0# 0x4005d0 => 0x00400547 <+7>: mulps (%rdi),%xmm0 0x0040054a <+10>:movups %xmm0,(%rdi) 0x0040054d <+13>:retq End of assembler dump. (gdb) p/x $rdi $2 = 0x7fffd7e4 There is an unaligned access. Tested revisions: trunk r231533 - FAIL 5-branch r231528 - OK 4_9-branch r231529 - OK
[Bug c/68473] [6 Regression] ICE: in contains_point, at diagnostic-show-locus.c:340 after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68473 --- Comment #9 from David Malcolm --- Updated patch kit posted here: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01291.html
[Bug tree-optimization/68861] New: [6 regression] FAIL: libgomp.fortran/vla8.f90 -O3 -g execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68861 Bug ID: 68861 Summary: [6 regression] FAIL: libgomp.fortran/vla8.f90 -O3 -g execution test Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: law at redhat dot com Blocks: 68619 Target Milestone: --- Target: aarch64-*-* $ gcc/xgcc -Bgcc/ ../libgomp/testsuite/libgomp.fortran/vla8.f90 -Baarch64-suse-linux/./libgomp/ -Baarch64-suse-linux/./libgomp/.libs -Iaarch64-suse-linux/./libgomp -I../include -I../libgomp -fopenmp -O3 -g -Baarch64-suse-linux/libgfortran/.libs -fintrinsic-modules-path=aarch64-suse-linux/libgomp -Laarch64-suse-linux/libgomp/.libs -Laarch64-suse-linux/libgfortran/.libs -lgfortran -lm -o ./vla8.exe $ LD_LIBRARY_PATH=.:aarch64-suse-linux/libgomp/.libs:gcc:aarch64-suse-linux/libgfortran/.libs:aarch64-suse-linux/libstdc++-v3/src/.libs ./vla8.exe Program aborted. Backtrace: Aborted (core dumped) 967524586c59bde314a890cd813242d37a9e9093 is the first bad commit git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@231527 138bc75d-0d04-0410-961f-82ee72b054a4 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68619 [Bug 68619] [6 Regression] error: loop with header 6 not in loop tree
[Bug debug/68848] allow -fdebug-prefix-map to read OLD prefix from environment (improve reproducibility)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68848 Daniel Kahn Gillmor changed: What|Removed |Added Attachment #37003|0 |1 is obsolete|| --- Comment #3 from Daniel Kahn Gillmor --- Created attachment 37004 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37004&action=edit allow reading OLD argument to -fdebug-prefix-map from environment (using ENV: prefix)
[Bug debug/68848] allow -fdebug-prefix-map to read OLD prefix from environment (improve reproducibility)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68848 Daniel Kahn Gillmor changed: What|Removed |Added Attachment #37004|0 |1 is obsolete|| --- Comment #4 from Daniel Kahn Gillmor --- Created attachment 37005 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37005&action=edit allow reading OLD argument to -fdebug-prefix-map from environment (using ENV: prefix)
[Bug debug/68848] allow -fdebug-prefix-map to read OLD prefix from environment (improve reproducibility)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68848 Daniel Kahn Gillmor changed: What|Removed |Added Attachment #37001|0 |1 is obsolete|| --- Comment #2 from Daniel Kahn Gillmor --- Created attachment 37003 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37003&action=edit allow reading OLD argument to -fdebug-prefix-map from environment (using ENV: prefix) the v3 patch fixes coding conventions (thanks, Bernd Schmidt!)
[Bug tree-optimization/68853] [6 Regression] gcc-6 miscompiles Chromium v8 garbage collector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68853
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #8 from Andrew Pinski ---
Calling a NULL object is undefined.
Address address() { return reinterpret_cast(this); }
bool is_valid() { return address() !=
# 475 "../../v8/src/heap/spaces.h" 3 4
__null
# 475 "../../v8/src/heap/spaces.h"
; }
That will always be true. That is this can never be NULL.
[Bug preprocessor/68854] isystem and ansi cause arm assembly preprocessing problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68854 --- Comment #2 from vasyl.vavrychuk at globallogic dot com --- --ansi is passed by build system of a big 3rd party project that I compile. It is possible to change it to remove --ansi but in my opinion there is gcc bug too. Gcc should either: * ignore ansi in the case of assembly source * report that ansi is invalid option
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 --- Comment #25 from Alexander --- ../gcc-4.8.5/configure \ --enable-languages=c,c++ --prefix=/import/home/nskdvlp/CC_Libs/CC/ia64-hp-hpux_11.31_-64 \ --with-local-prefix=/usr/CC/ia64-hp-hpux_11.31_-64 --with-gnu-as \ --with-as=/usr/local/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld \ --disable-nls --disable-libgcj --enable-shared --enable-threads=posix --with-dwarf2 \ --disable-libgomp SED=/usr/local/bin/sed SHELL=/usr/bin/bash --enable-lto is my configure cmd line (but libs inlace in tree)
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 --- Comment #24 from John Buddery --- You can use --disable-libgomp in the configure command, I had to do this on my HP builds.
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 --- Comment #23 from The Written Word --- (In reply to Alexander from comment #22) > I tried using libgomp but is the same as your error has occurred. > After that , I only used libgmp, libmpc and libmpfr ( in the GCC source tree > ) . How do you avoid libgomp? When building 4.8.5, we're using out-of-tree gmp-5.1.2, mpfr-3.1.2, and mpc-1.0.3.
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 --- Comment #22 from Alexander --- I tried using libgomp but is the same as your error has occurred. After that , I only used libgmp, libmpc and libmpfr ( in the GCC source tree ) .
[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64919 --- Comment #21 from The Written Word --- I built gcc-4.7.4 with the change to gcc/config/ia64/hpux.h of "#undef MAKE_DECL_ONE_ONLY" and just tried building gcc-4.8.5. Is anyone else seeing this when trying to build libgomp: /opt/build/gcc-4.8.5/libgomp/parallel.c: In function 'omp_get_ancestor_thread_num': /opt/build/gcc-4.8.5/libgomp/parallel.c:169:1: internal compiler error: in plus_constant, at explow.c:86 omp_get_ancestor_thread_num (int level) ^
[Bug ipa/68851] [6 Regression] ICE: in set_comdat_group, at ipa-comdats.c:213
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68851 --- Comment #5 from Markus Trippelsdorf --- Created attachment 37002 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37002&action=edit unreduced testcase Reducing is very slow. Here is the unreduced testcase.
[Bug ipa/68851] [6 Regression] ICE: in set_comdat_group, at ipa-comdats.c:213
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68851 --- Comment #4 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68851 > > --- Comment #3 from Martin Liška --- > So the mentioned revision is responsible for creation of a new consprop clone: > > IPA decision stage: > ... > - Creating a specialized node of virtual bool > blink::HTMLFormControlElement::isFormControlElement() const/14820 for all > known > contexts. > ... > IPA constant propagation end This is fine. At this point we should have the clone and thunks associated with it that are local and have no compdat group. > > > and the symbol is identified to be set to a comdat group in ipa-comdats.c:365: > > if (is_a (symbol)) >dyn_cast *>(symbol)->call_for_symbol_thunks_and_aliases > (set_comdat_group_1, >*comdat_head_map.get (group), >true); > > as the function calls 'set_comdat_group_1' for the constprop cloned function, > the original function of the clone is thunk and calls the clone. So that > set_comdat_group_1 > is called for the original function: > > _ZThn96_NK5blink22HTMLFormControlElement20isFormControlElementEv/14822 > (virtual > bool > blink::HTMLFormControlElement::_ZThn96_NK5blink22HTMLFormControlElement20isFormControlElementEv() > const) @0x7fffeb51b8a0 > Type: function definition analyzed > Visibility: externally_visible asm_written public weak comdat > comdat_group:_ZNK5blink22HTMLFormControlElement20isFormControlElementEv > one_only > section:.text._ZNK5blink22HTMLFormControlElement20isFormControlElementEv > (implicit_section) virtual artificial > Same comdat group as: > _ZNK5blink22HTMLFormControlElement20isFormControlElementEv.constprop.39/31390 > Aux: @0x1 References: > Referring: > Availability: available > First run: 0 > Function flags: nonfreeing_fn > Thunk fixed offset -96 virtual value 0 has virtual offset 0) > Called by: > Calls: > _ZNK5blink22HTMLFormControlElement20isFormControlElementEv.constprop.39/31390 > (1.00 per call) (can throw external) When do we put _ZNK5blink22HTMLFormControlElement20isFormControlElementEv.constprop.39 to the same comdat group? Perhaps we forget to clear comdat groups after cloning? Honza > > constprop clone: > > _ZNK5blink22HTMLFormControlElement20isFormControlElementEv.constprop.39/31390 > () @0x7fffe8bc6000 > Type: function definition analyzed > Visibility: > comdat_group:_ZNK5blink22HTMLFormControlElement20isFormControlElementEv > Same comdat group as: > _ZNK5blink22HTMLFormControlElement20isFormControlElementEv/14820 > previous sharing asm name: 31394 > References: > Referring: > Clone of _ZNK5blink22HTMLFormControlElement20isFormControlElementEv/14820 > Availability: local > First run: 0 > Function flags: local nonfreeing_fn > Called by: > _ZThn96_NK5blink22HTMLFormControlElement20isFormControlElementEv/14822 (1.00 > per call) (can throw external) > Calls: > > Problem is that the original function has already set comdat_group here: > > #0 symtab_node::set_comdat_group (this=0x7fffeb51b8a0, group=0x7fffeb4dc620) > at ../../gcc/cgraph.h:220 > #1 0x00a53972 in symtab_node::add_to_same_comdat_group > (this=0x7fffeb51b8a0, old_node=0x7fffeb51b5c0) at ../../gcc/symtab.c:461 > #2 0x008d05e2 in use_thunk (thunk_fndecl=0x7fffeb4ec7e0, emit_p=true) > at ../../gcc/cp/method.c:396 > #3 0x008e2979 in emit_associated_thunks (fn=0x7fffeb4dc620) at > ../../gcc/cp/semantics.c:4080 > #4 0x008e2cb8 in expand_or_defer_fn (fn=0x7fffeb4dc620) at > ../../gcc/cp/semantics.c:4178 > #5 0x0087a103 in cp_parser_function_definition_after_declarator > (parser=0x77feeb40, inline_p=true) at ../../gcc/cp/parser.c:25212 > #6 0x0087b772 in cp_parser_late_parsing_for_member > (parser=0x77feeb40, member_function=0x7fffeb4dc620) at > ../../gcc/cp/parser.c:26033 > #7 0x008745f7 in cp_parser_class_specifier_1 (parser=0x77feeb40) > at ../../gcc/cp/parser.c:21412 > #8 0x008746bb in cp_parser_class_specifier (parser=0x77feeb40) at > ../../gcc/cp/parser.c:21438 > #9 0x0086b65b in cp_parser_type_specifier (parser=0x77feeb40, > flags=1, decl_specs=0x7fffd6b0, is_declaration=true, > declares_class_or_enum=0x7fffd634, is_cv_qualifier=0x7fffd633) at > ../../gcc/cp/parser.c:15736 > #10 0x00867008 in cp_parser_decl_specifier_seq (parser=0x77feeb40, > flags=1, decl_specs=0x7fffd6b0, declares_class_or_enum=0x7fffd6ac) at > ../../gcc/cp/parser.c:12657 > #11 0x00866645 in cp_parser_simple_declaration (parser=0x77feeb40, > function_definition_allowed_p=true, maybe_range_for_decl=0x0) at > ../../gcc/cp/parser.c:12200 > #12 0x008665cd in cp_parser_block_declaration (parser=0x77feeb40, > statement_p=false) at ../../gcc/cp/parser.c:12147 > #13 0x0086634f in cp_parser_declaration (parser=0x77feeb40) at > ../..
[Bug debug/68860] New: [6 regression] FAIL: gcc.dg/guality/pr36728-1.c -O3 -g line 16 arg1 == 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860 Bug ID: 68860 Summary: [6 regression] FAIL: gcc.dg/guality/pr36728-1.c -O3 -g line 16 arg1 == 1 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: hubicka at gcc dot gnu.org Target Milestone: --- Target: aarch64-*-*, ia64-*-* Breakpoint 1, foo (arg7=, arg6=, arg5=, arg4=, arg3=, arg2=, arg1=) at /usr/local/gcc/gcc-20151211/gcc/testsuite/gcc.dg/guality/pr36728-1.c:12 12char *x = __builtin_alloca (arg7); $1 = $2 = 1 != 1 FAIL: gcc.dg/guality/pr36728-1.c -O3 -g line 16 arg1 == 1 15a1fce36358508909f2013fd6d07e0b9fcad97a is the first bad commit git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@231540 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug preprocessor/68854] isystem and ansi cause arm assembly preprocessing problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68854 --- Comment #1 from Richard Earnshaw --- ANSI is a dialect of C. Why are you passing that flag to an assembler file?
[Bug target/68841] [6 Regression] gcc.c-torture/execute/pr59358.c FAILs with custom compiler flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68841 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org --- Comment #3 from ktkachov at gcc dot gnu.org --- I'll have a look.
[Bug debug/68848] allow -fdebug-prefix-map to read OLD prefix from environment (improve reproducibility)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68848 Daniel Kahn Gillmor changed: What|Removed |Added Attachment #36989|0 |1 is obsolete|| --- Comment #1 from Daniel Kahn Gillmor --- Created attachment 37001 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37001&action=edit allow reading OLD argument to -fdebug-prefix-map from environment (using ENV: prefix) I'm attaching an updated patch that uses an "ENV:" prefix instead of a literal "$", because the "$" is messy to pass through a complex build chain without a lot of escaping. So the reproducible use case would be something like: export SOURCE_BUILD_DIR="$(pwd)" gcc -fdebug-prefix-map=ENV:SOURCE_BUILD_DIR=/usr/src
[Bug tree-optimization/66740] [6 Regression] omp simd reduction miscompiles at -O3 with AVX (recent regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66740 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Can you still reproduce it? I don't see anything wrong on the dumps I've looked at, without -Ofast of course the order of the floating point arithmetics is significantly different between -fopenmp and -fno-openmp - but that is to be expected, you've asked for that. So, for the iterations that are vectorized, each SIMD lane has its own sum variable (with the given options the loop seems to be vectorized with vectorization factor 8, so there are 8 SIMD lanes and thus 8 separate sum vars), the vector version sums up into those (initialized with 0), any scalar iterations sum into the first SIMD lane's sum var and finally at the end the 8 partial sums are summed together (one by one, rather than what vectorizer normally does for -Ofast reduce them by summing up 4 x 2 numbers, then 2 x 2 numbers, then 2 numbers. If this is still a problem, can you cook up a small self-contained testcase out of it (small function with just the #pragma omp simd loop in it, taking the args as parameters, with noinline/noclone attribute on it ideally, and then main that fills up an array with the problematic input values and then checks what the function returned (sum))?
[Bug testsuite/35710] FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35710 --- Comment #17 from Dominique d'Humieres --- > Feel free to commit your patch, Dominique. You've been faster with providing > a fix. :) (But maybe incorporate the whitespace fixes as well.) Done.
[Bug target/33120] Data not put in BSS section on Mac OS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33120 --- Comment #27 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Fri Dec 11 16:39:49 2015 New Revision: 231571 URL: https://gcc.gnu.org/viewcvs?rev=231571&root=gcc&view=rev Log: 2015-12-11 Jan-Benedict Glaw Dominique d'Humieres PR target/26427 PR target/33120 PR testsuite/35710 * config/darwin.c (darwin_use_anchors_for_symbol_p): Fix indention and trailing whitespace. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.c
[Bug target/26427] with -fsection-anchors with zero sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26427 --- Comment #25 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Fri Dec 11 16:39:49 2015 New Revision: 231571 URL: https://gcc.gnu.org/viewcvs?rev=231571&root=gcc&view=rev Log: 2015-12-11 Jan-Benedict Glaw Dominique d'Humieres PR target/26427 PR target/33120 PR testsuite/35710 * config/darwin.c (darwin_use_anchors_for_symbol_p): Fix indention and trailing whitespace. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.c
[Bug testsuite/35710] FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35710 --- Comment #16 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Fri Dec 11 16:39:49 2015 New Revision: 231571 URL: https://gcc.gnu.org/viewcvs?rev=231571&root=gcc&view=rev Log: 2015-12-11 Jan-Benedict Glaw Dominique d'Humieres PR target/26427 PR target/33120 PR testsuite/35710 * config/darwin.c (darwin_use_anchors_for_symbol_p): Fix indention and trailing whitespace. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.c
[Bug c++/68859] Add a less strict/smarter version of -Wreorder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68859 --- Comment #1 from Ryan Johnson --- (I would be happy to do some legwork on this if somebody is willing to send a few pointers by PM. I know the code in gcc/cp/init.c, particularly functions `perform_member_init` and `sort_mem_initializers` are relevant, but would need some help figuring out how to traverse trees and pick out uses of member variables from other members' initializers)
[Bug fortran/68744] FAIL: gfortran.dg/backtrace_1.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68744 --- Comment #4 from dave.anglin at bell dot net --- On 2015-12-11 6:45 AM, dominiq at lps dot ens.fr wrote: > Is this PR fixed by revision r231485? No. It just fixed the undefined __sync function warnings from HP ld. The above revision was applied when this PR was reported. The problem here is we no longer get any backtrace. Haven't had a chance to determine why.
[Bug c++/68859] New: Add a less strict/smarter version of -Wreorder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68859
Bug ID: 68859
Summary: Add a less strict/smarter version of -Wreorder
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scovich at gmail dot com
Target Milestone: ---
I am working with a large legacy code base that triggers a huge number of
warnings when compiled with -Wreorder (or -Wall, which enables it).
I am not making any excuses for that code, but still it would be nice to have a
weaker-but-smarter variant of -Wreorder that only triggers when the
initialization order actually matters. For example, in the .cpp below, the
warning triggered by struct `definitely_bad` is helpful and identifies a real
bug. The warning for struct `not_a_problem`, on the other hand, is
significantly less interesting because each member is initialized completely
independently of the others (***). The middle example is evil because it calls
a member function of a partially constructed object, so I don't think it much
matters whether this smarter warning would trip or not in that case.
= example.cpp ==
struct definitely_bad {
int val;
int *ptr;
definitely_bad(int *p) : ptr(p), val(*ptr) { }
};
struct bad_for_a_different_reason {
int val;
int *ptr;
bad_for_a_different_reason(int *p)
: ptr(p), val(do_something()) { }
int do_something();
};
struct not_a_problem {
int val;
int *ptr;
not_a_problem(int* p, int v) : ptr(p), val(v) { }
};
Basically, I could imagine building a dependency graph that tracks which member
initializers depend on other members, and then trigger the warning only if the
true initialization order is not a valid partial order in that graph.
(***) I realize that members could have constructors with global side effects
(e.g. calls to printf or changes to global variables). I that case changing the
initialization order would still be observable, but this seems like a rare
enough case that the proposed warning could ignore it (leaving the existing
-Wreorder to flag it if the user desires).
[Bug testsuite/35710] FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35710 --- Comment #15 from Jan-Benedict Glaw --- Feel free to commit your patch, Dominique. You've been faster with providing a fix. :) (But maybe incorporate the whitespace fixes as well.) Actually, there are some more in the initial commit, but cleaning them up without really fixing something just only makes rebasing more difficult.
[Bug target/68841] [6 Regression] gcc.c-torture/execute/pr59358.c FAILs with custom compiler flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68841 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-11 CC||jakub at gcc dot gnu.org, ||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Started with r227368.
[Bug c/68833] [6 Regression] -Werror=format issues an error now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68833 --- Comment #3 from Jakub Jelinek --- Created attachment 37000 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37000&action=edit gcc6-pr68833.patch Untested fix.
[Bug rtl-optimization/64818] User specified register don't work correctly in inline-asm operands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64818 Richard Earnshaw changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c++/68810] FAIL: g++.dg/cpp0x/constexpr-reinterpret1.C -- test for errors -- -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68810 David Edelsohn changed: What|Removed |Added CC||dje at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org --- Comment #9 from David Edelsohn --- PowerPC -m32 (including AIX) also.
[Bug ipa/66616] [4.9/5/6 regression] fipa-cp-clone ignores thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66616 --- Comment #8 from Martin Jambor --- After looking at all the wrong places I finally found the correct one. I have proposed a fix on the mailing list: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01271.html
[Bug testsuite/35710] FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35710 --- Comment #14 from Dominique d'Humieres --- > Created attachment 36996 [details] > Patch to fix indention/trailing whitespace Similar patch posted at https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01249.html and approved at https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01251.html (without the trailing whitespace fix). Are you planning to commit the patch or do you want me to do it?
[Bug tree-optimization/68775] [6 Regression] spec2006 test case 465.tonto fails with the gcc 6.0 fortran compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68775 --- Comment #10 from William Seurer --- It fails with -fdbg-cnt=vect_slp:31 and succeeds with -fdbg-cnt=vect_slp:30
[Bug tree-optimization/68853] [6 Regression] gcc-6 miscompiles Chromium v8 garbage collector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68853
--- Comment #7 from Markus Trippelsdorf ---
The while loop in:
421 void IncrementalMarking::ActivateIncrementalWriteBarrier() {
422 ActivateIncrementalWriteBarrier(heap_->old_space());
423 ActivateIncrementalWriteBarrier(heap_->map_space());
424 ActivateIncrementalWriteBarrier(heap_->code_space());
425 ActivateIncrementalWriteBarrier(heap_->new_space());
426
427 LargePage* lop = heap_->lo_space()->first_page();
428 while (lop->is_valid()) {
429 SetOldSpacePageFlags(lop, true, is_compacting_);
430 lop = lop->next_page();
431 }
432 }
Good: Bad:
.p2align 4,,10 .p2align 4,,10
.p2align 3 .p2align 3
.L2183:.L2176:
orq $12, 8(%rax) orq $12, 8(%rax)
movq176(%rax), %raxmovq176(%rax), %rax
testq %rax, %rax jmp .L2176
jne .L2183
rep ret
.L2192:
rep ret
[Bug c++/68858] New: Cannot use fold expression in requirements with two parameters packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68858
Bug ID: 68858
Summary: Cannot use fold expression in requirements with two
parameters packs
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: public at alisdairm dot net
Target Milestone: ---
Created attachment 36999
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36999&action=edit
demonstrates requires clause does not recognize parameter packs are constrained
to same length
I am trying to re-implement pair using variadic templates, constrained to a
pack size of exactly two, in order to use fold expressions to simplify
exception specifications and other constraints. However, I get a hard
(non-SFINAEable) error every time I instantiate my class template, complaining
that parameter packs are not the same length. Source attached, but in brief,
this is my attempt to contain the packs:
template
requires(2 == sizeof...(TYPES))
struct MyPair {
template
requires sizeof...(TYPES) == sizeof...(OTHER_TYPES)
and (true and ... and is_constructible())
constexpr
MyPair(OTHER_TYPES&&... args)
noexcept((true and ... and is_nothrow_constructible()));
};
Error message:
error: mismatched argument pack lengths while expanding
'std::is_constructible()'
requires sizeof...(TYPES) == sizeof...(OTHER_TYPES) and (true and ...
and std::is_constructible())
(note that the example triggering this error does not try to invoke that
constructor, and it parses fine until the implicitly instantiated class
template performs name-lookup for a constructor).
Testing against latest gcc 6 available from MacPorts: g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin15/6.0.0/lto-wrapper
Target: x86_64-apple-darwin15
Configured with:
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc6/gcc6/work/gcc-6-20151129/configure
--prefix=/opt/local --build=x86_64-apple-darwin15
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc6 --includedir=/opt/local/include/gcc6
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-6 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-6
--with-gxx-include-dir=/opt/local/include/gcc6/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local
--enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--with-pkgversion='MacPorts gcc6 6-20151129_0'
Thread model: posix
gcc version 6.0.0 20151129 (experimental) (MacPorts gcc6 6-20151129_0)
[Bug target/26427] with -fsection-anchors with zero sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26427 --- Comment #24 from Jan-Benedict Glaw --- Created attachment 36998 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36998&action=edit Patch to fix indention/trailing whitespace
