[Bug libstdc++/61166] overflow when parse number in std::duration operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61166 --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Kan Liu from comment #10) _Select_type already does the overflow check, so *template implemented operators* is still redundant I think. You can't use _Select_type on a literal operator that is not a template. Since the standard units (std::hours, milliseconds ...) requires the duration::rep to be *int64_t*, No it doesn't, only chrono::nanoseconds is required to have a 64-bit representation. chrono::hours and chrono::minutes are allowed to have fewer than 32 bits (at least 23 bits and at least 29 bits respectively). there's no need to do too much check. Not all values of uint64_t fit in int64_t
[Bug libstdc++/60966] std::call_once sometime hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #25 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Leon Timmermans from comment #24)
get_future() is non-const, set_value() is non-const.
I can see your point from a C++ point of view, but this doesn't make sense
from a usable threading point of view. IMHO, the whole point of abstractions
such as promises is to isolate the user from such issues.
Within reason yes, but not entirely. You can't expect to safely assign to the
same std::promise in two threads for example.
Anyway, that's not the real issue here, the example can be fixed to avoid such
race conditions but still demonstrate the problem:
#include future
#include thread
#include vector
struct DummyTask {
DummyTask(int id) : id_(id) {}
int id_;
std::promisevoid 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(std::futurevoid fut) {
fut.wait();
}
int main() {
std::vectorconst DummyTask* tasks;
std::vectorstd::thread threads;
std::vectorstd::futurevoid futures;
for (int i = 0; i THREADS; ++i) {
DummyTask* task = new DummyTask(i);
tasks.push_back(task);
futures.push_back(task-pr.get_future());
threads.emplace_back(run_task, task);
}
for (int i = 0; i THREADS; ++i) {
wait_for_task(std::move(futures[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();
}
}
[Bug libstdc++/60966] std::call_once sometime hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966 --- Comment #26 from Thomas Sanchez thomas.sanchz at gmail dot com --- In the end the problem is quite simple :) One workaround would be to move the promise into the lambda however I would be glad that your patch get accepted, because IMHO it is not an expected behavior from a user point of view ! Thanks a lot for your work !
[Bug libstdc++/61166] overflow when parse number in std::duration operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61166 --- Comment #12 from Kan Liu kan.liu.229 at gmail dot com --- (In reply to Jonathan Wakely from comment #11) (In reply to Kan Liu from comment #10) _Select_type already does the overflow check, so *template implemented operators* is still redundant I think. You can't use _Select_type on a literal operator that is not a template. Since the standard units (std::hours, milliseconds ...) requires the duration::rep to be *int64_t*, No it doesn't, only chrono::nanoseconds is required to have a 64-bit representation. chrono::hours and chrono::minutes are allowed to have fewer than 32 bits (at least 23 bits and at least 29 bits respectively). there's no need to do too much check. Not all values of uint64_t fit in int64_t Wow... I see
[Bug middle-end/61196] Optimizer does not handle memory accesses with two pointers to same location correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61196 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- The code breaks the aliasing rules of ISO C and thus has undefined behavior. Compile with -Wstrict-aliasing=1 to get a warning and -fno-strict-aliasing to ask it to be forgiving about the violation.
[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 #13 from Jakub Jelinek jakub at gcc dot gnu.org --- I vaguely remember it has been seen in the wild, not sure how often, but there were several bugreports about that. In any case, I'd say it is a pitty to stop optimizing this case for the unlikely case there is no move insn, the needed pending moves should be around and thus can be also verified in the wider mode, the question is if we want to do a linear search for them, or have some faster way to find them.
[Bug tree-optimization/61197] [4.10 Regression] wrong code at -O3 on x86_64-linux (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61197 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-16 CC||glisse at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target Milestone|--- |4.10.0 Summary|wrong code at -O3 on|[4.10 Regression] wrong |x86_64-linux (in both |code at -O3 on x86_64-linux |32-bit and 64-bit modes)|(in both 32-bit and 64-bit ||modes) Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r210212.
[Bug tree-optimization/61197] [4.10 Regression] wrong code at -O3 on x86_64-linux (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61197 --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Zhendong Su from comment #0) It seems different from PR 61140 and PR 61150 as -fno-tree-dce makes both disappear, but not this one. Still the same bug (fixed by the same patch). I am sorry it is taking me so long to commit it, it has been approved but I am traveling this week. Maybe tomorrow.
[Bug tree-optimization/61197] [4.10 Regression] wrong code at -O3 on x86_64-linux (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61197 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Make sure to add all the various testcases.
[Bug c++/61198] Crash when selecting specializations through aliases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61198 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Severity|blocker |normal
[Bug c++/61198] Crash when selecting specializations through aliases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61198 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Closely related to c++/60767
[Bug tree-optimization/61194] [4.9/4.10 Regression] vectorization failed with bit-precision arithmetic not supported even if conversion to int is requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 32803 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32803action=edit patch Like this.
[Bug libstdc++/61166] overflow when parse number in std::duration operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61166 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Fri May 16 09:30:57 2014 New Revision: 210511 URL: http://gcc.gnu.org/viewcvs?rev=210511root=gccview=rev Log: 2014-05-15 Ed Smith-Rowland 3dw...@verizon.net Jonathan Wakely jwak...@redhat.com PR libstdc++/61166 * include/bits/parse_numbers.h: Use integral_constant to remove duplication and simplify. * testsuite/20_util/duration/literals/61166.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/duration/literals/61166.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/parse_numbers.h
[Bug tree-optimization/61194] [4.9/4.10 Regression] vectorization failed with bit-precision arithmetic not supported even if conversion to int is requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194
--- Comment #7 from vincenzo Innocente vincenzo.innocente at cern dot ch ---
great!
the original version (that vectorized in 4.8.1)
void barX() {
for (int i=0; i1024; ++i) {
k[i] = (x[i]0) (w[i]y[i]);
z[i] = (k[i]) ? z[i] : y[i];
}
}
does not vectorize yet.
On the other hand I am very happy to see
void bar() {
for (int i=0; i1024; ++i) {
auto c = ( (x[i]0) (w[i]y[i])) | (y[i]0.5f);
z[i] = c ? y[i] : z[i];
}
}
vectorized
if (c) z[i] = y[i];
does not even with -ftree-loop-if-convert-stores
not a real issue at least for what I am concerned
[Bug tree-optimization/61194] [4.9/4.10 Regression] vectorization failed with bit-precision arithmetic not supported even if conversion to int is requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194
--- Comment #8 from rguenther at suse dot de rguenther at suse dot de ---
On Fri, 16 May 2014, vincenzo.innocente at cern dot ch wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194
--- Comment #7 from vincenzo Innocente vincenzo.innocente at cern dot ch ---
great!
the original version (that vectorized in 4.8.1)
void barX() {
for (int i=0; i1024; ++i) {
k[i] = (x[i]0) (w[i]y[i]);
z[i] = (k[i]) ? z[i] : y[i];
}
}
does not vectorize yet.
That's because we hit
check_bool_pattern (var=ssa_name 0x76c36e10, loop_vinfo=0x1f3e900,
bb_vinfo=0x0)
at /space/rguenther/src/svn/trunk/gcc/tree-vect-patterns.c:2596
2596 dt))
...
2605 if (!has_single_use (def))
2606return false;
because
_5 = x[i_18];
_6 = _5 0.0;
_7 = w[i_18];
_8 = y[i_18];
_9 = _7 _8;
_10 = _9 _6;
_11 = (int) _10;
k[i_18] = _11;
iftmp.0_13 = z[i_18];
iftmp.0_2 = _10 ? iftmp.0_13 : _8;
thus we have CSEd the load from k and propagated from the
conversion. VRP does this:
_11 = (int) _10;
- k[i_1] = _11;
- if (_11 != 0)
+ k[i_18] = _11;
+ if (_10 != 0)
and -fno-tree-vrp fixes the regression. If k were of type
_Bool then it likely wouldn't vectorize with 4.8 either.
The vectorizer cannot handle multi-uses of a pattern part
(in this case it's the start which would be doable, but it's
far from trivial ...). That said,
static float x[1024];
static float y[1024];
static float z[1024];
static float w[1024];
static _Bool k[1024];
void __attribute__((noinline,noclone)) barX()
{
int i;
for (i=0; i1024; ++i) {
k[i] = (x[i]0) (w[i]y[i]);
z[i] = (k[i]) ? z[i] : y[i];
}
}
is not vectorized even in 4.8 for the cited reason.
On the other hand I am very happy to see
void bar() {
for (int i=0; i1024; ++i) {
auto c = ( (x[i]0) (w[i]y[i])) | (y[i]0.5f);
z[i] = c ? y[i] : z[i];
}
}
vectorized
if (c) z[i] = y[i];
does not even with -ftree-loop-if-convert-stores
not a real issue at least for what I am concerned
I think it doesn't introduce data races unless you
also specify --param allow-store-data-races=1.
I also don't see the testcases vectorized when using
instead of .
If not already there, these warrant (different) bugreports.
[Bug middle-end/61199] New: [trans-mem] _cxa_free_exception is not transaction safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61199 Bug ID: 61199 Summary: [trans-mem] _cxa_free_exception is not transaction safe Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: torvald at gcc dot gnu.org Created attachment 32804 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32804action=edit test case See attached test case. I'm not quite sure how we need to handle it: Is this only called when another transaction has taken over, and we're freeing up garbage? Or can a call to this create a situation in which we canceled a previous exception throw? If the latter case holds, I guess we also need to reset the transaction-in-flight state that libitm keeps when cxa_allocate_exception is called. Depending on this, we either need to make it TM-pure or add a wrapper in libitm. Thoughts?
[Bug middle-end/61199] [trans-mem] _cxa_free_exception is not transaction safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61199 torvald at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-16 CC||aldyh at gcc dot gnu.org, ||jason at gcc dot gnu.org, ||rth at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/54316] [C++11] move constructor for stringstream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54316 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-16 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/59352] Internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59352 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Feedback not forthcoming.
[Bug c++/58899] g++ seg faulted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58899 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Feedback not forthcoming.
[Bug tree-optimization/61194] [4.9/4.10 Regression] vectorization failed with bit-precision arithmetic not supported even if conversion to int is requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri May 16 11:21:11 2014 New Revision: 210514 URL: http://gcc.gnu.org/viewcvs?rev=210514root=gccview=rev Log: 2014-05-16 Richard Biener rguent...@suse.de PR tree-optimization/61194 * tree-vect-patterns.c (adjust_bool_pattern): Also handle bool patterns ending in a COND_EXPR. * gcc.dg/vect/pr61194.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr61194.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-patterns.c
[Bug tree-optimization/61194] [4.9/4.10 Regression] vectorization failed with bit-precision arithmetic not supported even if conversion to int is requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 32805 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32805action=edit patch fixing the regression This would fix the regression (also without the previous patch?)
[Bug tree-optimization/61194] [4.9/4.10 Regression] vectorization failed with bit-precision arithmetic not supported even if conversion to int is requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194
--- Comment #11 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Richard Biener from comment #10)
Created attachment 32805 [details]
patch fixing the regression
This would fix the regression (also without the previous patch?)
It does, on the 4.9 branch at least, for
static float x[1024];
static float y[1024];
static float z[1024];
static float w[1024];
static int k[1024];
void __attribute__((noinline,noclone)) barX()
{
int i;
for (i=0; i1024; ++i)
{
k[i] = x[i]0;
k[i] = w[i]y[i];
z[i] = (k[i]) ? z[i] : y[i];
}
}
but it doesn't change the outcome of the big testcase in the original report.
It does together with the other patch though:
g++-4.9 t.C -Ofast -ftree-loop-if-convert-stores -fopt-info-vec -B. -fopenmp
t.C:11:5: note: loop vectorized
t.C:19:23: note: loop vectorized
t.C:24:5: note: loop vectorized
t.C:29:5: note: loop vectorized
t.C:35:5: note: loop vectorized
t.C:41:5: note: loop vectorized
t.C:47:5: note: loop vectorized
bar2 still not vectorized there.
But with 4.7 I see the same as with 4.8 and 4.9:
35: LOOP VECTORIZED.
41: LOOP VECTORIZED.
47: LOOP VECTORIZED.
so where exactly does the regression part appear for you? Is that only
for the code in comment#1?
[Bug tree-optimization/61194] [4.9/4.10 Regression] vectorization failed with bit-precision arithmetic not supported even if conversion to int is requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194
--- Comment #12 from Richard Biener rguenth at gcc dot gnu.org ---
void bar2() {
for (int i=0; i1024; ++i) {
k[i] = x[i]0; j[i] = w[i]0;
z[i] = ( k[i] j[i]) ? z[i] : y[i];
}
}
has similar issues (non-single-uses due to CSE and propagating from the
conversion sources):
_5 = x[i_20];
_6 = _5 0.0;
_7 = (int) _6;
k[i_20] = _7;
_9 = w[i_20];
_10 = _9 0.0;
_11 = (int) _10;
j[i_20] = _11;
_18 = _10 _6;
iftmp.0_14 = z[i_20];
iftmp.0_15 = y[i_20];
iftmp.0_2 = _18 ? iftmp.0_14 : iftmp.0_15;
z[i_20] = iftmp.0_2;
This is generally caused by optimizing code to use smaller precisions. So
I think we need a more general solution for this than just the 2nd patch
I attached (which I won't pursue - I figure the first one would be way
more useful as it results in the same result for your initial large testcase
where the 2nd patch doesn't make a difference).
[Bug tree-optimization/61194] [4.9/4.10 Regression] vectorization failed with bit-precision arithmetic not supported even if conversion to int is requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194 --- Comment #13 from vincenzo Innocente vincenzo.innocente at cern dot ch --- I confirm that with last patch the regression is gone also in a more complex actual application I had. The regression concerns only comment 2 and 3. all the other cases in comment 1 were various attempt of mine to see if anything was changed that allowed vectorization using a different syntax. I am happy that now they all vectorize (but bar2...) when, in 2011, I wrote the original test case, I introduced the int vector to make it vectorize (most probably I also submitted a bug report on the subject)
[Bug tree-optimization/61194] [4.9/4.10 Regression] vectorization failed with bit-precision arithmetic not supported even if conversion to int is requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61194 --- Comment #14 from vincenzo Innocente vincenzo.innocente at cern dot ch --- provided that future patches will make the code in comment 1 and 2 (and bar) go vectorize is fine with me. if it ends up to vectorize also with bool instead of int even better. (I am not sure that bit/byte handling is really more efficient in sse and avx w.r.t plain 32bit int)
[Bug libstdc++/60758] Infinite backtrace in __cxa_end_cleanup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60758 --- Comment #4 from merzlyakovao at gcc dot gnu.org --- Author: merzlyakovao Date: Fri May 16 13:16:33 2014 New Revision: 210515 URL: http://gcc.gnu.org/viewcvs?rev=210515root=gccview=rev Log: 2014-05-16 Alexey Merzlyakov alexey.merzlya...@samsung.com PR libstdc++/60758 * libsupc++/eh_arm.cc (__cxa_end_cleanup): Change r4 to lr in save/restore and add unwind directives. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/eh_arm.cc
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #5 from christophe.lyon at st dot com --- Created attachment 32806 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32806action=edit ELF binary file
[Bug libgomp/61200] New: internal compiler error: Segmentation fault, assert openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61200 Bug ID: 61200 Summary: internal compiler error: Segmentation fault, assert openmp Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: psxlover at hotmail dot com CC: jakub at gcc dot gnu.org Created attachment 32807 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32807action=edit Minimal test case When trying to compile attached file with -fopenmp I get a segmentation fault. Tried with gcc 4.4.5 (on debian squeeze), 4.8.2 (on cygwin, fedora 20 and debian wheezy) and 4.9.0 and all of them crash. The problem occurs when there is an assert in a parallel region containing a variable and then you have a task with that variable as share and you access it in any way. The problem doesn't occur if the assert is not in a #pragma omp parallel or if you change he following task to parallel, or if you remove the shared directive from the task or finally if you don't access the variable inside the task. The assert call can contain anything as long as it contains the variable that is accessed later in a task. Here is the output of ./gcc-4.9.0/bin/gcc -v -save-temps -fopenmp fopenmpSeg.c: Using built-in specs. COLLECT_GCC=./gcc-4.9.0/bin/gcc COLLECT_LTO_WRAPPER=/home/psxlover/gcc-4.9.0/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/psxlover/Downloads/gcc4.9obj/../gcc-4.9.0/configure --prefix=/home/psxlover/gcc-4.9.0 --disable-multilib Thread model: posix gcc version 4.9.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mtune=generic' '-march=x86-64' '-pthread' /home/psxlover/gcc-4.9.0/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1 -E -quiet -v -D_REENTRANT fopenmpSeg.c -mtune=generic -march=x86-64 -fopenmp -fpch-preprocess -o fopenmpSeg.i ignoring nonexistent directory /home/psxlover/gcc-4.9.0/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /home/psxlover/gcc-4.9.0/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include /usr/local/include /home/psxlover/gcc-4.9.0/include /home/psxlover/gcc-4.9.0/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-mtune=generic' '-march=x86-64' '-pthread' /home/psxlover/gcc-4.9.0/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/cc1 -fpreprocessed fopenmpSeg.i -quiet -dumpbase fopenmpSeg.c -mtune=generic -march=x86-64 -auxbase fopenmpSeg -version -fopenmp -o fopenmpSeg.s GNU C (GCC) version 4.9.0 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.9.0, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.9.0 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.9.0, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 24a1e3ed1d75ecc9aae55f188f0fd7ae fopenmpSeg.c: In function ‘main’: fopenmpSeg.c:8:28: internal compiler error: Segmentation fault assert(var == 1); ^ 0x8e103f crash_signal /home/psxlover/Downloads/gcc4.9obj/../gcc-4.9.0/gcc/toplev.c:337 0x7723e1 gimplify_expr(tree_node**, gimple_statement_base**, gimple_statement_base**, bool (*)(tree_node*), int) /home/psxlover/Downloads/gcc4.9obj/../gcc-4.9.0/gcc/gimplify.c:8376 0x779cd0 gimple_regimplify_operands(gimple_statement_base*, gimple_stmt_iterator*) /home/psxlover/Downloads/gcc4.9obj/../gcc-4.9.0/gcc/gimplify-me.c:172 0x82853b lower_omp_1 /home/psxlover/Downloads/gcc4.9obj/../gcc-4.9.0/gcc/omp-low.c:10139 0x82853b lower_omp /home/psxlover/Downloads/gcc4.9obj/../gcc-4.9.0/gcc/omp-low.c:10151 0x82cca4 lower_omp_taskreg /home/psxlover/Downloads/gcc4.9obj/../gcc-4.9.0/gcc/omp-low.c:9485 0x828dfe lower_omp_1 /home/psxlover/Downloads/gcc4.9obj/../gcc-4.9.0/gcc/omp-low.c:10016 0x828dfe lower_omp /home/psxlover/Downloads/gcc4.9obj/../gcc-4.9.0/gcc/omp-low.c:10151 0x8292dc lower_omp_1 /home/psxlover/Downloads/gcc4.9obj/../gcc-4.9.0/gcc/omp-low.c:10008 0x8292dc lower_omp /home/psxlover/Downloads/gcc4.9obj/../gcc-4.9.0/gcc/omp-low.c:10151 0x82ad6a execute_lower_omp /home/psxlover/Downloads/gcc4.9obj/../gcc-4.9.0/gcc/omp-low.c:10183 0x82ad6a execute /home/psxlover/Downloads/gcc4.9obj/../gcc-4.9.0/gcc/omp-low.c:10222 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.
[Bug target/59904] [ARM] tls-reload-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #6 from christophe.lyon at st dot com --- I have re-run the tests with trunk@210140 and older binutils (Sept 2013). The test fails at compilation with target arm-none-linux-gnueabi, and CFLAGS=-Os -pie -fpie or -Os -pie -fPIE in the following configurations: --with-mode=arm --with-cpu=cortex-a9 --with-mode=arm --with-cpu=cortex-a9 RUNTESTFLAGS=-mthumb --with-mode=thumb --with-cpu=cortex-a9 --with-mode=thumb --with-cpu=cortex-a9 RUNTESTFLAGS=-marm The test compiles OK and fails at execution with --with-mode=thumb --with-cpu=cortex-a9 RUNTESTFLAGS=-march=armv5t (this is the ELF file I have attached) The compiles and runs OK with --with-mode=arm --with-cpu=cortex-a9 RUNTESTFLAGS=-march=armv5t
[Bug libstdc++/58962] Pretty printers use obsolete Python syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58962 GonzaloBonigo gonzalo.bonigo at tallertechnologies dot com changed: What|Removed |Added CC||gonzalo.bonigo@tallertechno ||logies.com --- Comment #2 from GonzaloBonigo gonzalo.bonigo at tallertechnologies dot com --- Please, assign it to me.
[Bug libstdc++/58962] Pretty printers use obsolete Python syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58962 --- Comment #3 from Daniel Gutson daniel.gutson at tallertechnologies dot com --- Please do not close this issue.(In reply to Bruce Merry from comment #1) I've now realised that this is actually just the tip of the iceberg - I suspect that libstdc++'s pretty printers aren't Python 3 ready, while Ubuntu is shipping a gdb linked to libython 3.3. Feel free to close if this is as expected. Please don't close this issue, it is completely relevant since not only for ubuntu but for other distros too. Syntax should work both with python versions 2 and 3 at ever possible.
[Bug libstdc++/58962] Pretty printers use obsolete Python syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58962 --- Comment #4 from Bruce Merry bmerry at gmail dot com --- Incidentally, the workaround I have been using is to just run the script through 2to3. Since Python only tells you things have gone wrong when you execute the code I can't guarantee that this fixes everything, but I've yet to hit any further Python 2 vs 3 issues after doing this.
[Bug libstdc++/61075] parallel std::accumulate reduct type cannot be different than the iterated type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61075
--- Comment #8 from Denes Matetelki denes.matetelki at gmail dot com ---
Just an observation:
The contained type also need to declare and define ctor(int).
Which can be tricky, if it is a template class and:
template typename T
class Custom
{
public:
Custom(T t) : m_t(t) {}
Custom(int i) : m_t() {}
explicit operator int() const { return convertToInt(m_t); }
private:
T m_t;
};
Customint c; // ambigous ctor(int)
[Bug libgcc/56846] _Unwind_Backtrace on ARM and noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-16 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1
[Bug libgomp/61200] internal compiler error: Segmentation fault, assert openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61200
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-05-16
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
More reduced testcase:
int
main ()
{
int var = 1;
#pragma omp parallel
if (var != 1)
__builtin_abort ();
#pragma omp task shared(var)
var = 2;
return 0;
}
The problem is that previously non-addressable var needs to be turned into
addressable because it is shared in the task, where we can't use copy-in/out,
but by that time we have already processed the #pragma omp parallel and decided
to copy-in/out var there, but later on it is TREE_ADDRESSABLE and thus we
expect that copy-in/out is not used in that case.
Unfortunately, I believe we really have to force no copy-in/out in that case,
consider:
#include omp.h
#include stdlib.h
#include unistd.h
volatile int x;
void
foo ()
{
int var = 1;
int i;
for (i = 0; i 2; i++)
{
if (i == 1)
{
#pragma omp parallel
if (x)
var++;
else
{
#pragma omp single
sleep (4);
}
}
else
{
#pragma omp task shared(var)
{
sleep (2);
var = 2;
}
}
}
#pragma omp taskwait
if (var != 2)
abort ();
}
int
main ()
{
omp_set_nested (1);
#pragma omp parallel
#pragma omp single
foo ();
return 0;
}
If we decide to use copy-in/out in #pragma omp parallel for var, but the task
will be run in parallel with the #pragma omp parallel, then if the #pragma omp
parallel is entered before var = 2 is set in another thread, it will copy in
value 1, then var = 2 happens and if #pragma omp parallel finishes after that,
it will copy out the value it copied in (1) and the testcase will break, even
when there is actually no data-race originally (the compiler doesn't know the
parallel will not touch var at all).
[Bug c++/51640] Misleading error if the type in the catch() is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51640 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED CC|paolo at gcc dot gnu.org | Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.9.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- I'm noticing this only today, sorry about that. Luckily, anyway, it's fixed and doesn't affect 4.9.0 and mainline. However, we can avoid a redundant error message, I'm tweaking that for 4.10.
[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 #19 from H.J. Lu hjl.tools at gmail dot com --- There is #define VALID_MMX_REG_MODE_3DNOW(MODE) \ ((MODE) == V2SFmode || (MODE) == SFmode) and ix86_hard_regno_mode_ok returns TRUE for holding SFmode in MMX registers. It is wrong to tell RA that MMX registers can have V2SFmode/SFmode when 3DNOW is disabled. Even if 3DNOW is enabled, we can't use MMX registers for floating point when x87 registers are also used.
[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 #14 from Jeffrey A. Law law at redhat dot com --- I'm not talking about restricting the general case where we've got cascaded extensions. Just the case where one of the insns in the cascade has a source/dest that are not the same register. Which is a case we didn't even try to optimize until 4.9.
[Bug ada/61201] New: Cross compile fails with SPARK_05 undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61201 Bug ID: 61201 Summary: Cross compile fails with SPARK_05 undefined Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: rth at gcc dot gnu.org restrict.ads:145:07: SPARK_05 is undefined (more references follow) gnatmake: /home/rth/work/gcc/git-4.9/gcc/ada/ali-util.adb compilation error make[3]: *** [gnatmake-re] Error 4 make[3]: Leaving directory `/home/rth/work/gcc/bld-arm/gcc/ada/tools' make[2]: *** [gnattools-cross] Error 2 make[2]: Leaving directory `/home/rth/work/gcc/bld-arm/gnattools' make[1]: *** [all-gnattools] Error 2 make[1]: Leaving directory `/home/rth/work/gcc/bld-arm' make: *** [all] Error 2 While this specific case is x86_64 cross arm, it happens with several other cross-compilation targets as well.
[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 #20 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
The problem is ira-costs.c. One pseudo gets equal costs for memory and all
classes. Therefore when non-mmx hard regs are not enough, a mmx is used.
After initialization of costs of reg classes for the pseudo, the costs are
never updated as all alternatives of insns where the pseudo occurs are
rejected.
The insn and the code in ira-costs.c in consideration are
(insn 26 25 27 4 (set (reg:SF 147 [ D.2423 ])
(float:SF (reg/v:SI 155 [ z ]))) 203 {*floatsisf2_i387}
(expr_list:REG_DEAD (reg/v:SI 155 [ z ])
(nil)))
(define_insn *floatSWI48x:modeMODEF:mode2_i387
[(set (match_operand:MODEF 0 register_operand =f)
(float:MODEF (match_operand:SWI48x 1 nonimmediate_operand m)))]
if (classes[i] == NO_REGS)
{
/* We must always fail if the operand is a REG, but
we did not find a suitable class.
Otherwise we may perform an uninitialized read
from this_op_costs after the `continue' statement
below. */
alt_fail = 1;
The code is originated from the old RA which is originated from reload in own
turn. The reload was not enable to deal with only 'm' alternative (when LRA
works well with only 'm').
I am working on the patch and I hope to commit it today into the branch and
trunk.
[Bug ada/61201] Cross compile fails with SPARK_05 undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61201 Arnaud Charlet charlet at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||charlet at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Arnaud Charlet charlet at gcc dot gnu.org --- You need a matching (built with same sources) native first to build a cross, I suspect that's the issue here.
[Bug target/61202] New: gcc generates invalid sqdmulh instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61202 Bug ID: 61202 Summary: gcc generates invalid sqdmulh instruction Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: carrot at google dot com Target: aarch64 Created attachment 32808 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32808action=edit testcase Attached is reduced preprocessed source code. Compile it with gcc 4.9 aarchobj/gcc/cc1 -fpreprocessed t3.i -quiet -dumpbase t3.i -mlittle-endian -mabi=lp64 -auxbase-strip t3.o -Os -o t3.s as -o t3.o t3.s t3.s: Assembler messages: t3.s:14: Error: register number out of range 0 to 15 at operand 3 -- `sqdmulh v4.8h,v0.8h,v16.h[0]' t3.s:42: Error: register number out of range 0 to 15 at operand 3 -- `sqdmulh v0.8h,v1.8h,v16.h[0]' The error message is very clear, the last operand of sqdmulh can only be low FP register.
[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 #21 from H.J. Lu hjl.tools at gmail dot com --- MMX and x87 registers are aliases of each others. They can't be used at the same time. Is there a way to pass this information to RA?
[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 #22 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Fri May 16 17:21:04 2014 New Revision: 210519 URL: http://gcc.gnu.org/viewcvs?rev=210519root=gccview=rev Log: 2014-05-16 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/60969 * ira-costs.c (record_reg_classes): Allow only memory for pseudo. Calculate costs for this case. 2014-05-16 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/60969 * g++.dg/pr60969.C: New. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/pr60969.C Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/ira-costs.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[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 #23 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Fri May 16 17:37:17 2014 New Revision: 210520 URL: http://gcc.gnu.org/viewcvs?rev=210520root=gccview=rev Log: 2014-05-16 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/60969 * ira-costs.c (record_reg_classes): Allow only memory for pseudo. Calculate costs for this case. 2014-05-16 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/60969 * g++.dg/pr60969.C: New. Added: trunk/gcc/testsuite/g++.dg/pr60969.C Modified: trunk/gcc/ChangeLog trunk/gcc/ira-costs.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51640] Misleading error if the type in the catch() is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51640 --- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Fri May 16 17:42:23 2014 New Revision: 210521 URL: http://gcc.gnu.org/viewcvs?rev=210521root=gccview=rev Log: /cp 2014-05-16 Paolo Carlini paolo.carl...@oracle.com PR c++/51640 * parser.c (cp_parser_diagnose_invalid_type_name): Early return when cp_parser_lookup_name sets ambiguous_decls. /testsuite 2014-05-16 Paolo Carlini paolo.carl...@oracle.com PR c++/51640 * g++.dg/parse/error54.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/error54.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51640] Misleading error if the type in the catch() is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51640 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug c/56724] sub-optimal location in error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 --- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Tom Tromey from comment #5) I tried this today with a recent-ish gcc trunk build, and there's been a regression. I think the problem is that convert_for_assignment uses location instead of expr_loc. The original issue is harder to fix. I am not sure we have locations for the different types in a function declaration, do we?
[Bug tree-optimization/61203] New: [4.7/4.8/4.9/4.10 Regression] g++.old-deja/g++.jason/rvalue2.C FAILs with -O2 -fno-inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61203 Bug ID: 61203 Summary: [4.7/4.8/4.9/4.10 Regression] g++.old-deja/g++.jason/rvalue2.C FAILs with -O2 -fno-inline Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 32809 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32809action=edit reduced testcase I think the code has defined behaviour. The temporal object created by A() is afaict alive when the pointer comparison is being done (but it is not when the result of the comparison is being used)... but it might easily happen that I am wrong; I am certainly not an C++ expert, the code is quite artificial. Attached is a reduced testcase. Output: $ g++ -O2 testcase.C $ ./a.out a.out: testcase.C:16: int main(): Assertion `!r' failed. Aborted Tested revisions: trunk r210490 - fail 4.9 r210307 - fail 4.8 r210303 - fail 4.7 r210302 - fail 4.6 r197894 - OK
[Bug go/61204] New: gccgo: ICE in in fold_convert_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61204
Bug ID: 61204
Summary: gccgo: ICE in in fold_convert_loc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
$ gccgo -v
Using built-in specs.
COLLECT_GCC=gccgo
COLLECT_LTO_WRAPPER=libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++,go --disable-bootstrap
--enable-checking=yes --disable-multilib --prefix=gcc_trunk/install
Thread model: posix
gcc version 4.10.0 20140516 (experimental) (GCC)
The program is:
package main
func main() {
type id2 chan map[uintptr]string
type id3 [0]string
type id4 float64
_ = --make(chan id2, cap(id3([0]string{})))
type id5 id2
_, _ = --make(chan chan string)
var id6 id5 = id5(id2(make(chan map[uintptr]string, ((1) + ((-make(chan
int, ((1) + ((1) + (([]int{})[((1) * (1))]) * ((1) + ((([]int{})[1]) +
(-make(chan int))) * ((-make(chan int)) + (1))) * (---make(chan chan chan
int, 1))) + (1)) * (-make(chan int)
type id7 id3
_, _, _ = map[id4]bool{}, ([]float64{})[1], (((make(chan chan chan
chan int, ((--make(chan chan int)) * (1 * (1)) +
(([]int{})[-make(chan chan chan chan chan int, 1)) + ((1) *
(((--make(chan chan []int))[1]) + (1 * ((([]int{})[--make(chan chan
int, ((1)*(1)))]) + ((--make(chan chan int)) * ((1) + (-make(chan int))
* (-make(chan int, 1)))]))
id8 := id7(id3([0]string{}))
_, _, _, id8 = [0]int{}, --make(chan chan [0]int), ((--make(chan chan
int, ([]int{})[([]int{})[-make(chan int)]])) + (--([]chan chan
int{})[-make(chan int, (---make(chan chan chan []int, 1))[-make(chan int,
1)])])), id7(id3([0]string{}))
_ = id8
_ = id6
}
$ go build -compiler=gccgo src.go
# command-line-arguments
go1: internal compiler error: in fold_convert_loc, at fold-const.c:2072
0x7ce963 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2072
0x5c6bc5 Gcc_backend::temporary_variable(Bfunction*, Bblock*, Btype*,
Bexpression*, bool, Location, Bstatement**)
../../gcc/go/go-gcc.cc:2483
0x6080a4 Temporary_statement::do_get_backend(Translate_context*)
../../gcc/go/gofrontend/statements.cc:460
0x5db097 Block::get_backend(Translate_context*)
../../gcc/go/gofrontend/gogo.cc:5454
0x60741c Block_statement::do_get_backend(Translate_context*)
../../gcc/go/gofrontend/statements.cc:1811
0x5db097 Block::get_backend(Translate_context*)
../../gcc/go/gofrontend/gogo.cc:5454
0x5dc925 Function::build(Gogo*, Named_object*)
../../gcc/go/gofrontend/gogo.cc:5062
0x5ddc57 Named_object::get_backend(Gogo*, std::vectorBexpression*,
std::allocatorBexpression* , std::vectorBtype*, std::allocatorBtype* ,
std::vectorBfunction*, std::allocatorBfunction* )
../../gcc/go/gofrontend/gogo.cc:6753
0x5e2b5c Gogo::write_globals()
../../gcc/go/gofrontend/gogo.cc:1136
[Bug go/61205] New: gccgo: ICE in fold_binary_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61205
Bug ID: 61205
Summary: gccgo: ICE in fold_binary_loc
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: dvyukov at google dot com
$ gccgo -v
Using built-in specs.
COLLECT_GCC=gccgo
COLLECT_LTO_WRAPPER=libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++,go --disable-bootstrap
--enable-checking=yes --disable-multilib --prefix=gcc_trunk/install
Thread model: posix
gcc version 4.10.0 20140516 (experimental) (GCC)
The program is:
package main
func main() {
(-(-make(chan chan func([1]string, float64) (chan string,
[0]bool([1]string{string(foo)}, 1.1)
_ = -(([][]chan uintptr{})[[][]int{})[1])[(-(-(-((([][][]chan chan
chan int{})[1])[1])[(-([]chan int{})[1])])))]) + (-make(chan int)))])[1]
}
$ go build -compiler=gccgo src.go
# command-line-arguments
go1: internal compiler error: in fold_binary_loc, at fold-const.c:10024
0x7a89fe fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:10021
0x7c609a fold_build2_stat_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:14998
0x5c5d0e Gcc_backend::compound_expression(Bstatement*, Bexpression*, Location)
../../gcc/go/go-gcc.cc:1439
0x5a7677 Call_expression::set_results(Translate_context*, Bexpression*)
../../gcc/go/gofrontend/expressions.cc:9540
0x5bb964 Call_expression::do_get_backend(Translate_context*)
../../gcc/go/gofrontend/expressions.cc:9498
0x60718c Expression_statement::do_get_backend(Translate_context*)
../../gcc/go/gofrontend/statements.cc:1749
0x5db097 Block::get_backend(Translate_context*)
../../gcc/go/gofrontend/gogo.cc:5454
0x5dc925 Function::build(Gogo*, Named_object*)
../../gcc/go/gofrontend/gogo.cc:5062
0x5ddc57 Named_object::get_backend(Gogo*, std::vectorBexpression*,
std::allocatorBexpression* , std::vectorBtype*, std::allocatorBtype* ,
std::vectorBfunction*, std::allocatorBfunction* )
../../gcc/go/gofrontend/gogo.cc:6753
0x5e2b5c Gogo::write_globals()
../../gcc/go/gofrontend/gogo.cc:1136
[Bug c/61081] excessive warnings: right-hand operand of comma expression has no effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61081 --- Comment #6 from Peter Eisentraut peter_e at gmx dot net --- This particular case is in system headers, but there are other cases that are not, so this isn't going to help in general. I think this is a legitimate way to write a function-like macro that has a side-effect and a return value, and the warning is bogus.
[Bug libfortran/61187] valgrind errors if stdin is closed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61187 --- Comment #1 from Janne Blomqvist jb at gcc dot gnu.org --- Author: jb Date: Fri May 16 20:37:13 2014 New Revision: 210527 URL: http://gcc.gnu.org/viewcvs?rev=210527root=gccview=rev Log: PR 61187 Fix use of uninitialized memory. 2014-05-16 Janne Blomqvist j...@gcc.gnu.org PR libfortran/61187 * io/unix.c (raw_close): Check if s-fd is -1. (fd_to_stream): Check return value of fstat(), handle error. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/unix.c
[Bug libfortran/61187] valgrind errors if stdin is closed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61187 --- Comment #2 from Janne Blomqvist jb at gcc dot gnu.org --- Author: jb Date: Fri May 16 20:42:56 2014 New Revision: 210529 URL: http://gcc.gnu.org/viewcvs?rev=210529root=gccview=rev Log: PR 61187 Fix use of uninitialized data. 2014-05-16 Janne Blomqvist j...@gcc.gnu.org Backport from trunk: PR libfortran/61187 * io/unix.c (raw_close): Check if s-fd is -1. (fd_to_stream): Check return value of fstat(), handle error. Modified: branches/gcc-4_7-branch/libgfortran/ChangeLog branches/gcc-4_7-branch/libgfortran/io/unix.c
[Bug libfortran/61187] valgrind errors if stdin is closed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61187 --- Comment #3 from Janne Blomqvist jb at gcc dot gnu.org --- Author: jb Date: Fri May 16 20:48:17 2014 New Revision: 210530 URL: http://gcc.gnu.org/viewcvs?rev=210530root=gccview=rev Log: PR 61187 Fix use of uninitialized data. 2014-05-16 Janne Blomqvist j...@gcc.gnu.org Backport from trunk: PR libfortran/61187 * io/unix.c (raw_close): Check if s-fd is -1. (fd_to_stream): Check return value of fstat(), handle error. Modified: branches/gcc-4_9-branch/libgfortran/ChangeLog branches/gcc-4_9-branch/libgfortran/io/unix.c
[Bug driver/61206] New: Duplicate -I- causes compiler to hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61206 Bug ID: 61206 Summary: Duplicate -I- causes compiler to hang Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: tprince at coverity dot com GCC hangs when (erroneously) given -I- and glibc reports a double free: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/pkg/gcc-4.9.0/libexec/gcc/i686-pc-linux-gnu/4.9.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/opt/pkg/gcc-4.9.0 --program-suffix=-4.9.0 --enable-languages=c,c++ Thread model: posix gcc version 4.9.0 (GCC) $ touch t.c $ mkdir foo bar $ gcc -c -I. -I- -Ifoo -I- -Ibar t.c cc1: note: obsolete option -I- used, please use -iquote instead cc1: error: -I- specified twice *** glibc detected *** /opt/pkg/gcc-4.9.0/libexec/gcc/i686-pc-linux-gnu/4.9.0/cc1: double free or corruption (fasttop): 0x0a3e97a0 *** === Backtrace: = /lib/libc.so.6[0x6abb16] /lib/libc.so.6(cfree+0x90)[0x6af030] /opt/pkg/gcc-4.9.0/libexec/gcc/i686-pc-linux-gnu/4.9.0/cc1(_Z17split_quote_chainv+0x39)[0x836e359] === Memory map: 002a5000-002b r-xp fd:00 1902901 /lib/libgcc_s-4.1.2-20080102.so.1 002b-002b1000 rwxp a000 fd:00 1902901 /lib/libgcc_s-4.1.2-20080102.so.1 00513000-00514000 r-xp 00513000 00:00 0 [vdso] 00625000-0063f000 r-xp fd:00 1902893/lib/ld-2.5.so 0063f000-0064 r-xp 00019000 fd:00 1902893/lib/ld-2.5.so 0064-00641000 rwxp 0001a000 fd:00 1902893/lib/ld-2.5.so 00643000-0078 r-xp fd:00 1902894/lib/libc-2.5.so 0078-00782000 r-xp 0013d000 fd:00 1902894/lib/libc-2.5.so 00782000-00783000 rwxp 0013f000 fd:00 1902894/lib/libc-2.5.so 00783000-00786000 rwxp 00783000 00:00 0 00788000-0078a000 r-xp fd:00 1902895/lib/libdl-2.5.so 0078a000-0078b000 r-xp 1000 fd:00 1902895/lib/libdl-2.5.so 0078b000-0078c000 rwxp 2000 fd:00 1902895/lib/libdl-2.5.so 0078e000-007b3000 r-xp fd:00 1902899/lib/libm-2.5.so 007b3000-007b4000 r-xp 00024000 fd:00 1902899/lib/libm-2.5.so 007b4000-007b5000 rwxp 00025000 fd:00 1902899/lib/libm-2.5.so 08048000-09448000 r-xp fd:00 5968643 /opt/pkg/gcc-4.9.0/libexec/gcc/i686-pc-linux-gnu/4.9.0/cc1 09448000-09451000 rw-p 0140 fd:00 5968643 /opt/pkg/gcc-4.9.0/libexec/gcc/i686-pc-linux-gnu/4.9.0/cc1 09451000-09509000 rw-p 09451000 00:00 0 0a3b8000-0a3fa000 rw-p 0a3b8000 00:00 0 b7a0-b7a21000 rw-p b7a0 00:00 0 b7a21000-b7b0 ---p b7a21000 00:00 0 b7b42000-b7d44000 rw-p b7b42000 00:00 0 b7d44000-b7f44000 r--p fd:00 9968315/usr/lib/locale/locale-archive b7f44000-b7f46000 rw-p b7f44000 00:00 0 b7f51000-b7f52000 rw-p b7f51000 00:00 0 bfb76000-bfb8b000 rw-p bfb76000 00:00 0 [stack] (null):0: confused by earlier errors, bailing out At which point the compiler hangs. I imagine this isn't worth fixing since it's an invalid command line and -I- is deprecated, but I figured I'd report it in case the relevant code is used elsewhere.
[Bug target/51244] [SH] Inefficient conditional branch and code around T bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #75 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Fri May 16 22:54:32 2014 New Revision: 210535 URL: http://gcc.gnu.org/viewcvs?rev=210535root=gccview=rev Log: gcc/ PR target/51244 * config/sh/sh.c (sh_eval_treg_value): Handle t_reg_operand and negt_reg_operand cases. * config/sh/sh.md (*cset_zero): Likewise by using cbranch_treg_value predicate. * config/sh/predicates.md (cbranch_treg_value): Simplify. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/predicates.md trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #31 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Fri May 16 23:12:19 2014 New Revision: 210537 URL: http://gcc.gnu.org/viewcvs?rev=210537root=gccview=rev Log: gcc/ PR target/54089 * config/sh/predicates.md (negt_reg_shl31_operand): Match additional patterns. * config/sh/sh.md (*negt_msb): Merge SH2A and non-SH2A variants. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/predicates.md trunk/gcc/config/sh/sh.md
[Bug middle-end/61207] New: Win64 gcc 4.9.0: ICE at -Os compiling some C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61207
Bug ID: 61207
Summary: Win64 gcc 4.9.0: ICE at -Os compiling some C++ code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mingw.android at gmail dot com
Created attachment 32810
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32810action=edit
testcase for Win64 gcc 4.9.0 ICE at -Os compiling some C++ code
I work on the MSYS2 project and we ran into:
g++ -Os -x c++ testcase.i
testcase.i: In constructor 'QQuickFlickablePrivate::QQuickFlickablePrivate()':
testcase.i:47:10: internal compiler error: in expand_expr_addr_expr_1, at
expr.c:7669
{}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://sourceforge.net/projects/msys2 for instructions.
This ICE doesn't happen at -O2 or when specifying the same flags that -Os
enables, so I think it is a specific size-optimization that causes this.
g++ --version
g++.exe (Rev4, Built by MSYS2 project) 4.9.0
.. I also tested with an unpatched version of 4.9.0 with the same results.
[Bug middle-end/61207] Win64 gcc 4.9.0: ICE at -Os compiling some C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61207 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Version|unknown |4.9.0 Severity|major |normal
[Bug target/61202] gcc generates invalid sqdmulh instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61202
--- Comment #1 from Carrot carrot at google dot com ---
In arm_neon.h, we have
__extension__ static __inline int16x8_t __attribute__ ((__always_inline__))
vqdmulhq_n_s16 (int16x8_t a, int16_t b)
{
int16x8_t result;
__asm__ (sqdmulh %0.8h,%1.8h,%2.h[0]
: =w(result)
: w(a), w(b)
: /* No clobbers */);
return result;
}
The register constraint for the last operand of sqdmulh is w, it means
FP_REGS, the correct constraint should be x, means FP_LO_REGS.
The trunk has the same problem.
[Bug target/61208] New: armhf: generated asm code produces branch out of range error in gas with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208 Bug ID: 61208 Summary: armhf: generated asm code produces branch out of range error in gas with -Os Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: mh+gcc at glandium dot org Created attachment 32811 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32811action=edit Preprocessed source (compressed) On Debian unstable, with debian gcc 4.8.2-21, the attached preprocessed source fails to build with: /tmp/cc9VIAtd.s: Assembler messages: /tmp/cc9VIAtd.s:827: Error: branch out of range
[Bug target/61208] armhf: generated asm code produces branch out of range error in gas with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61208 --- Comment #1 from Mike Hommey mh+gcc at glandium dot org --- Created attachment 32812 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32812action=edit Corresponding assembly (compressed) This is the assembly I got with the full normal command line. But I can reproduce with the following command line: g++ -o CertVerifier.o -c CertVerifier.ii -Os -std=gnu++0x The problematic line is a cbz call, and i guess the label ends up at more than 130 bytes from the call.
[Bug other/56811] [4.8/4.9/4.10 Regression] libbacktrace causes undefined symbol _Unwind_GetIPInfo on ia64-hpux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56811
Alexander alm at sibmail dot ru changed:
What|Removed |Added
CC||alm at sibmail dot ru
--- Comment #10 from Alexander alm at sibmail dot ru ---
build gcc-4.8.2 on HP-UX 11.31 IA64 fails.
The problem is in the change to check function _Unwind_GetIPInfo present.
In the 4.8.x autoconf compile test added:
$as_echo_n checking for _Unwind_GetIPInfo... 6; }
cat confdefs.h - _ACEOF conftest.$ac_ext
/* end confdefs.h. */
#include unwind.h
struct _Unwind_Context *context;
int ip_before_insn = 0;
int
main ()
{
return _Unwind_GetIPInfo (context, ip_before_insn);
;
return 0;
}
Build compiller has function _Unwind_GetIPInfo in fixinclude unwind.h:
extern _Unwind_Ptr _Unwind_GetIPInfo (struct _Unwind_Context *, int *);
comment it out - fix this problem.
But now problem in the stage1 xgcc: it has segmentation fault in
cc1 while compile simple c test:
checking for ia64-hp-hpux11.31-gcc...
/import/home/nskdvlp/Melnikov/gcc-4.8/build/./gcc/xgcc
-B/import/home/nskdvlp/Melnikov/gcc-4.8/build/./gcc/
-B/import/home/nskdvlp/Melnikov/gcc-4.8/gcc.x1/ia64-hp-hpux11.31/bin/
-B/import/home/nskdvlp/Melnikov/gcc-4.8/gcc.x1/ia64-hp-hpux11.31/lib/ -isystem
/import/home/nskdvlp/Melnikov/gcc-4.8/gcc.x1/ia64-hp-hpux11.31/include -isystem
/import/home/nskdvlp/Melnikov/gcc-4.8/gcc.x1/ia64-hp-hpux11.31/sys-include
sendsig: useracc failed. 0xb200 0x005000
Pid 6320 was killed due to failure in writing the signal context - possible
stack overflow.
checking for suffix of object files...
sendsig: useracc failed. 0xb200 0x005000
Pid 6325 was killed due to failure in writing the signal context - possible
stack overflow.
configure: error: in
`/import/home/nskdvlp/Melnikov/gcc-4.8/build/ia64-hp-hpux11.31/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
gmake[2]: *** [configure-stage1-target-libgcc] Error 1
gmake[2]: Leaving directory `/import/home/nskdvlp/Melnikov/gcc-4.8/build'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/import/home/nskdvlp/Melnikov/gcc-4.8/build'
gmake: *** [all] Error 2
[Bug target/44557] internal compiler error: in gen_thumb_movhi_clobber, at config/arm/arm.md:5811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44557 Sandra Loosemore sandra at codesourcery dot com changed: What|Removed |Added CC||sandra at codesourcery dot com --- Comment #9 from Sandra Loosemore sandra at codesourcery dot com --- The testcase (as packaged with Chung-Lin's patch) no longer fails on 4.9.0 or mainline. Has the problem gone away due to all the register allocator changes since it was initially reported against GCC 4.5, or is it simply being masked by them?
