[Bug testsuite/65594] New: libgomp.graphite/force-parallel-6.c timeout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65594 Bug ID: 65594 Summary: libgomp.graphite/force-parallel-6.c timeout Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org I run the gcc test suite with -j9 on an i7-930 (8 logical cores, 4 physical cores) and 12 GB memory, and Ubuntu 14.04.1 LTS. The only timeout I see is libgomp.graphite/force-parallel-6.c, and it occurs regurarly, though not always: ... PASS: libgomp.graphite/force-parallel-6.c (test for excess errors) WARNING: program timed out. FAIL: libgomp.graphite/force-parallel-6.c execution test ... The timeout is 300 seconds: ... build/gcc/xgcc -Bbuild/gcc/ src/libgomp/testsuite/libgomp.graphite/force-parallel-6.c -Bbuild/x86_64-unknown-linux-gnu/./libgomp/ -Bbuild/x86_64-unknown-linux-gnu/./libgomp/.libs -Ibuild/x86_64-unknown-linux-gnu/./libgomp -Isrc/libgomp/testsuite/../../include -Isrc/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -fdiagnostics-color=never -fopenmp -ansi -pedantic-errors -O2 -ftree-parallelize-loops=4 -floop-parallelize-all -fdump-tree-parloops-details -fdump-tree-optimized -fno-loop-strip-mine -fno-loop-block -fdump-tree-graphite-all -Lbuild/x86_64-unknown-linux-gnu/./libgomp/.libs -lm -o ./force-parallel-6.exe(timeout = 300) ... The time to run it on a system not running any other tests is rougly one second ... ( export LD_LIBRARY_PATH=".:build/x86_64-unknown-linux-gnu/./libgomp/.libs:build/gcc:build/gcc/32:.:build/x86_64-unknown-linux-gnu/./libgomp/.libs:build/gcc:build/gcc/32:build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs:build/x86_64-unknown-linux-gnu/libsanitizer/.libs:build/x86_64-unknown-linux-gnu/libvtv/.libs:build/x86_64-unknown-linux-gnu/libcilkrts/.libs:build/x86_64-unknown-linux-gnu/libssp/.libs:build/x86_64-unknown-linux-gnu/libgomp/.libs:build/x86_64-unknown-linux-gnu/libitm/.libs:build/x86_64-unknown-linux-gnu/libatomic/.libs:build/./gcc:build/./prev-gcc:infra/lib"; time ./force-parallel-6.exe ) real0m0.294s user0m1.128s sys0m0.041s ...
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #25 from Jan Hubicka --- The memory use report: rtl.c:317 (copy_rtx)9610680: 1.6% 0: 0.0% 0: 0.0% 0: 0.0% 401870 tree.c:8281 (build_method_type_directly)2839536: 0.5% 0: 0.0%6803496: 3.5% 0: 0.0% 57399 cfg.c:222 (connect_src) 9958800: 1.6% 0: 0.0% 0: 0.0% 0: 0.0% 248970 cfg.c:232 (connect_dest) 10182184: 1.7% 94040: 0.0% 0: 0.0% 0: 0.0% 254404 cp/pt.c:11057 (tsubst_decl) 1826688: 0.3% 0: 0.0%8401536: 4.4% 0: 0.0% 79908 emit-rtl.c:3852 (make_insn_raw)11540800: 1.9% 0: 0.0% 64: 0.0% 0: 0.0% 180326 cp/pt.c:3696 (reduce_template_parm_level) 3402072: 0.6% 0: 0.0%8579552: 4.4% 0: 0.0% 78853 tree.c:6521 (build_distinct_type_copy) 498792: 0.1% 0: 0.0% 11808384: 6.1% 0: 0.0% 73257 gimple-expr.c:486 (create_tmp_var_raw) 12338640: 2.0% 0: 0.0% 0: 0.0% 0: 0.0% 85685 cp/lex.c:674 (copy_type)3760344: 0.6% 0: 0.0%9471840: 4.9% 0: 0.0% 78763 fold-const.c:2229 (fold_convert_loc) 13500256: 2.2% 0: 0.0% 14400: 0.0% 0: 0.0% 422333 tree-inline.c:712 (remap_block)12999184: 2.1% 0: 0.0%1007072: 0.5% 0: 0.0% 159162 cp/pt.c:7051 (coerce_template_parms) 14424944: 2.4% 0: 0.0% 612088: 0.3% 0: 0.0% 359017 cp/pt.c:10272 (tsubst_template_args) 13006088: 2.1% 0: 0.0%3179968: 1.6% 0: 0.0% 377257 cp/lex.c:636 (copy_decl) 317760: 0.1% 0: 0.0% 17295456: 9.0% 0: 0.0% 94604 gimple.c:1687 (gimple_copy)18912384: 3.1% 0: 0.0% 0: 0.0% 107608: 0.8% 217479 tree-ssanames.c:166 (make_ssa_name_fn) 24862536: 4.1% 0: 0.0% 0: 0.0% 0: 0.0% 345313 cfg.c:148 (alloc_block)24957400: 4.1% 0: 0.0% 0: 0.0% 0: 0.0% 239975 tree-inline.c:5000 (copy_tree_r) 33060096: 5.4% 0: 0.0%736: 0.0% 0: 0.0% 815260 hash-table.h:1336 (alloc_entries) 31255400: 5.2%5441592: 2.1%4493776: 2.3% 416848: 3.0% 71795 Total 606753058262201484 193060957 13796011 15521861 source location GarbageFreed Leak OverheadTimes I suppose I could try to dig into who is producing so many of hash tables.
[Bug lto/65536] LTO line number information garbled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 --- Comment #46 from Jan Hubicka --- Manuel, I will hopefully commit the cache patch today or tomorrow morning. It does not solve full issue. What we have is 1) we still drop columns for firefox&chromium pretty early 2) there is a bug that we sometimes output wrong line number. I think it is caused by the logic reallocating ORDINARY_MAP_NUMBER_OF_COLUMN_BITS as described in original email. It would be nice to fix those. > My guess is that the motivation here is that, if there is a large gap, it > means that we didn't get asked any source_location since a lot of lines ago. > thus it would save a lot of source_locations to simply start a new map now. > Of course, this does not work for out-of-order, but why should we pessimize > typical usage for something that should be fixed in LTO? I do not think typical usage is pesimized here. Yes, code is trying to avoid case where we skip too many location indexes because we entered lines 1...30 and now we want to insert line 1000. We do not want to fast forward by 970*80. My code keeps this logic, only it allows ordering lines backward. > > 2) (line_delta > 10 && line_delta * ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) > > > 1000) > >ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) is in range 7... 15, so it never > >gets high enough to make this conditional trigger. I changed it to: > > I don't understand this. A line_delta of 67 (1000/15) will already trigger it. You are right, I misread the condition. > > 4) the code deciding whether to do reuse seems worng: > > if (line_delta < 0 > > || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map) > > || SOURCE_COLUMN (map, highest) >= (1U << column_bits)) > > > >line_delta really should be base_line_delta, we do not need to give up > >when map's line is 1, SOURCE_LINE (map, set->highest_line) is 5 > >and we are requested to switch to line 3. > > If you insert a line out of order without creating a new map, then > linemap_position_for_column will return the wrong value. I do not see why. If we insert first line 1 (80 columns), then we create a map 1. Now we insert line 3, we do not create new map, but we offset highest_line by 80*2. Now if we start line 2, all we need is to offset highest_line by -80 and linemap_position_for_column will still work well. Of course when we get request for column that is out of range, we need to trigger creation of new map entry. What I am missing here?
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #24 from Jan Hubicka --- Author: hubicka Date: Fri Mar 27 04:02:28 2015 New Revision: 221719 URL: https://gcc.gnu.org/viewcvs?rev=221719&root=gcc&view=rev Log: PR ipa/65076 * passes.def: Add pass_nothrow. * ipa-pure-const.c: (pass_data_nothrow): New. (pass_nothrow): New. (pass_nothrow::execute): New. (make_pass_nothrow): New. * tree-pass.h (make_pass_nothrow): Declare. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-pure-const.c trunk/gcc/passes.def trunk/gcc/tree-pass.h
[Bug c++/65575] [c++-concepts] Parse error for requires clause on functions that return a reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65575 --- Comment #2 from Tom Honermann --- r221695 does correct the specific test case in comment 0. However, I'm still seeing similar errors for function declarations that don't specify the return type with a trailing return type: $ svn info # From my local svn gcc repo. Path: . URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 221697 Node Kind: directory Schedule: normal Last Changed Author: asutton Last Changed Rev: 221695 Last Changed Date: 2015-03-26 09:35:54 -0400 (Thu, 26 Mar 2015) $ cat t2.cpp template concept bool C = true; int& f() requires C; $ g++ -c -std=c++1z t2.cpp t2.cpp:3:10: error: expected initializer before ‘requires’ int& f() requires C; ^
[Bug target/65593] [5 Regression] internal compiler error: in extract_insn, at recog.c:2343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65593 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-27 CC||tmsriram at google dot com Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- It was caused by r218397.
[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005 --- Comment #15 from Hans-Peter Nilsson --- (In reply to Jonathan Wakely from comment #14) > Can we close this? I can't say now, sorry, but will be back on this in a week.
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #23 from Jan Hubicka --- Also with early-inlining-insns=11 the statement count is smaller for mainline (copmared to 4.9) until the pass bswap, it grows up in PRE (by about 1%) and then it continues growing with subsequent passes. So it seems we make them considerably more busy...
[Bug target/65593] New: [5 Regression] internal compiler error: in extract_insn, at recog.c:2343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65593
Bug ID: 65593
Summary: [5 Regression] internal compiler error: in
extract_insn, at recog.c:2343
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
On Linux/x86-64, r221697 gave:
[hjl@gnu-35 gcc-test-spec]$ ./usr/bin/gcc -S -fPIE -O2 -o /tmp/x.s
src-trunk/gcc/testsuite/gcc.c-torture/compile/pr20928.c
src-trunk/gcc/testsuite/gcc.c-torture/compile/pr20928.c: In function
\u2018foo\u2019:
src-trunk/gcc/testsuite/gcc.c-torture/compile/pr20928.c:10:1: error:
unrecognizable insn:
}
^
(insn 7 6 8 2 (set (reg/f:DI 88)
(plus:DI (symbol_ref:DI ("bar") [flags 0x40] )
(reg:DI 89)))
src-trunk/gcc/testsuite/gcc.c-torture/compile/pr20928.c:8 -1
(expr_list:REG_EQUAL (const:DI (plus:DI (symbol_ref:DI ("bar") [flags
0x40] )
(const_int 2147483648 [0x8000])))
(nil)))
src-trunk/gcc/testsuite/gcc.c-torture/compile/pr20928.c:10:1: internal compiler
error: in extract_insn, at recog.c:2343
0xa9a2c8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src-trunk/gcc/rtl-error.c:110
0xa9a2f9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src-trunk/gcc/rtl-error.c:118
0xa68659 extract_insn(rtx_insn*)
../../src-trunk/gcc/recog.c:2343
0x86d1f3 instantiate_virtual_regs_in_insn
../../src-trunk/gcc/function.c:1598
0x86d1f3 instantiate_virtual_regs
../../src-trunk/gcc/function.c:1966
0x86d1f3 execute
../../src-trunk/gcc/function.c:2015
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[hjl@gnu-35 gcc-test-spec]$
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-27 Ever confirmed|0 |1 --- Comment #22 from Jan Hubicka --- With the nothrow pass added into into-ssa queue, I now get same statement counts after into_ssa as in 4.9. At release_ssa time, the statement count is 4% higher (down from 7%). This is due to change of inline-insns-early parameter and using --param early-inlining-insns=11 makes the instruction count actually 2% lower than for 4.9. Curious fact is that mainline does 4158 early inlines, reducing early-inlining-insns=11 increase number of inlines to 4695 while 4.9 does 4843. So it seems that more early inlining somehow blocks itself later. (in addition to the early inlining limit bump, early inliner now does uses predicates to anticipate DCE) Statement count in .optimize dump is 7% up and with --param early-inlining-insns=11 3% up. Instruction count is 9% up. Code segment is now 547066 compared to 4.9's 490807 (11% up). Early-inlining-insns has minimal effect. I will check if I can try to guide inliner to get more out of line functions removed.
[Bug c++/65592] New: internal compiler error: Segmentation fault when using non-existant enum class enumerator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65592
Bug ID: 65592
Summary: internal compiler error: Segmentation fault when using
non-existant enum class enumerator
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tim.pavlic at minelab dot com.au
Source to reproduce:
struct Foo
{
enum class Bar
{
BAZ
};
};
void take_bar(Foo::Bar /*bar*/)
{
}
int main()
{
Foo f;
f.Bar::NON_EXISTANT_ENUMERATOR;
take_bar(f.Bar::NON_EXISTANT_ENUMERATOR);
}
I have the above source in a single file, ice.cpp, and compile with: g++
-std=c++11 ice.cpp
Don't know if it should, but the line f.Bar::NON_EXISTANT_ENUMERATOR is
ignored.
The call to take_bar(f.Bar::NON_EXISTANT_ENUMERATOR) is what causes the ICE.
The problem also exists in 4.8.2
[Bug libstdc++/60421] std::this_thread::sleep_for doesn't sleep for all arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60421 Jonathan Wakely changed: What|Removed |Added Target Milestone|5.0 |6.0 --- Comment #7 from Jonathan Wakely --- You're right, sorry, I ended up reducing the scope of the fix and it only deals with PR58038, see https://gcc.gnu.org/ml/libstdc++/2015-03/msg00078.html for some commentary. At one point I added: if (__s < chrono::seconds::zero() || __s < __rtime) __s = chrono::seconds::max(); which would detect some cases where the duration_cast to chrono::seconds overflows, but that overflow is still undefined behaviour so I didn't include that in the commit. I want to fix it properly to avoid any undefined behaviour (probably converting to duration and comparing to duration::max()). > I mean when I sleep for UINT64_MAX hours/years/millenia, you can't possibly > wrap that into a single nanosleep call due to the limitations of the type > time_t of the tv_sec parameter of the first argument to nanosleep. One > obviously can not get around using loop. To be honest, I'm not very concerned about the failure to sleep for 290 billion years, if we sleep for duration::max() instead of duration::max() and don't loop you'll never know the difference. > Additionally, the nanosleep code is also missing proper EINTR handling, > which again could break the sleep. Yes, see the mailing list post above. I'll deal with this for gcc 6.
[Bug target/65510] target-tic6x: unrecognizable insn with -O(1,2,3,s).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65510 --- Comment #5 from Chen Gang --- After remove clobber (match_scratch ...), it will generate the correct assembly code (I guess it is): .file "test.i" .c6xabi_attribute Tag_ABI_array_object_alignment, 0 .c6xabi_attribute Tag_ABI_array_object_align_expected, 0 .c6xabi_attribute Tag_ABI_stack_align_needed, 0 .c6xabi_attribute Tag_ABI_stack_align_preserved, 0 .c6xabi_attribute Tag_ABI_conformance, "1.0" .text; .align 2 .global oxu_driver_init .type oxu_driver_init, @function oxu_driver_init: mvk .d1 11, A4 ldnw.d1t1 *A4, A3 nop 4 stnw.d1t1 A3, *A4 ret .s2 B3 nop 5 .size oxu_driver_init, .-oxu_driver_init .ident "GCC: (GNU) 5.0.0 20150321 (experimental)" And also can cross building Linux kernel with allmodconfig successfully. I shall send patch for it, next.
[Bug pch/61250] Random pch failures on x86_64-apple-darwin1(3|4).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 --- Comment #16 from howarth at bromo dot med.uc.edu --- (In reply to howarth from comment #15) > (In reply to howarth from comment #14) > > Testing https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01334.html in case > > correction of the overflow tests eliminates this bug. > > The proposed patch for correcting overflows doesn't eliminate this bug. With Jan's patch the failure still appears as... #0 0x7fff96238286 in __pthread_kill () #1 0x7fff9488042f in pthread_kill () #2 0x7fff8e9c1b53 in abort () #3 0x000100f32170 in linemap_lookup (set=0x10175e0f0, line=651) at ../../gcc-5-20150326/libcpp/line-map.c:806
[Bug pch/61250] Random pch failures on x86_64-apple-darwin1(3|4).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 --- Comment #15 from howarth at bromo dot med.uc.edu --- (In reply to howarth from comment #14) > Testing https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01334.html in case > correction of the overflow tests eliminates this bug. The proposed patch for correcting overflows doesn't eliminate this bug.
[Bug target/65510] target-tic6x: unrecognizable insn with -O(1,2,3,s).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65510 --- Comment #4 from Chen Gang --- In gcc/config/c6x/c6x.md, if we remove (clober ...) for movmisalign_store, it will be OK (just symmetric with movmisalign_load which is OK). (define_insn_and_split "movmisalign_store" [(set (match_operand:SIDIVM 0 "memory_operand" "=W,Q,T,Q,T") (unspec:SIDIVM [(match_operand:SIDIVM 1 "register_operand" "r,a,b,b,a")] UNSPEC_MISALIGNED_ACCESS)) (clobber (match_scratch:SI 2 "=r,X,X,X,X"))] I shall try to analyze why clobber match_scratch will cause issue.
[Bug target/65561] avx512fintrin.h:5344:1: internal compiler error: in curr_insn_transform, at lra-constraints.c:3494
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65561 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Uroš Bizjak --- Fixed for 4.9.3+.
[Bug target/65561] avx512fintrin.h:5344:1: internal compiler error: in curr_insn_transform, at lra-constraints.c:3494
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65561 --- Comment #8 from uros at gcc dot gnu.org --- Author: uros Date: Thu Mar 26 22:14:07 2015 New Revision: 221712 URL: https://gcc.gnu.org/viewcvs?rev=221712&root=gcc&view=rev Log: PR target/65561 * config/i386/sse.md (avx512f_vextract32x4_1_maskm): Check operand 6 and operand 0 for equality. (vec_extract_lo__maskm): Check operand 2 and operand 0 for equality. (vec_extract_hi__maskm): Ditto. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/i386/sse.md
[Bug c/65586] -fopenmp-simd rejects valid input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65586 --- Comment #3 from Jakub Jelinek --- Comment on attachment 35157 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35157 Untested draft patch I'd say the C++ parser change is ok, but the C parser change is not, I think c_parser_skip_until_found will not do gcc_assert (parser->in_pragma); parser->in_pragma = false; at the beginning and parser->error = false; at the end. So, perhaps add (optional?) bool argument to c_parser_skip_to_pragma_eol whether it should report the error if not already at CPP_PRAGMA_EOL (the default case), or whether it should use c_parser_next_token_is/c_parser_consume_token instead?
[Bug libstdc++/60421] std::this_thread::sleep_for doesn't sleep for all arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60421 Jaak Ristioja changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from Jaak Ristioja --- I mean when I sleep for UINT64_MAX hours/years/millenia, you can't possibly wrap that into a single nanosleep call due to the limitations of the type time_t of the tv_sec parameter of the first argument to nanosleep. One obviously can not get around using loop. Additionally, the nanosleep code is also missing proper EINTR handling, which again could break the sleep. Reopening.
[Bug fortran/65590] FAIL: gfortran.dg/coarray/coindexed_3.f90 -fcoarray=single -O2 -latomic (test for errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65590 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-03-26 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- This should have been fixed by r221618, see https://gcc.gnu.org/ml/fortran/2015-03/msg00124.html.
[Bug libstdc++/60421] std::this_thread::sleep_for doesn't sleep for all arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60421 --- Comment #5 from Jaak Ristioja --- (In reply to Jonathan Wakely from comment #4) > Fixed for gcc5. Looking at the diff of revision 221708, I fail to see how the if (__rtime <= __rtime.zero()) return; check in sleep_for() prevents the EINVAL in nanosleep(3p), as is the original issue. I mean aren't we dealing here with unsigned (decltype(_rtime)) to signed (std::time_t) conversion?
[Bug c/65586] -fopenmp-simd rejects valid input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65586 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-03-26 Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Tobias Burnus --- Created attachment 35157 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35157&action=edit Untested draft patch
[Bug libgomp/65589] OpenMP 3.1 produces random results for simple array copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65589 --- Comment #9 from felix.ospald at gmx dot de --- Hi, I attached an output from strace ./main 2>&1 | tee log Maybe this helps. I see that there are some futex EAGAIN errors. I'm not sure if this is a problem (I also get them on my notebook).
[Bug libgomp/65589] OpenMP 3.1 produces random results for simple array copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65589 --- Comment #8 from felix.ospald at gmx dot de --- Created attachment 35156 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35156&action=edit strace output
[Bug target/65561] avx512fintrin.h:5344:1: internal compiler error: in curr_insn_transform, at lra-constraints.c:3494
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65561 Uroš Bizjak changed: What|Removed |Added Target Milestone|--- |4.9.3 --- Comment #7 from Uroš Bizjak --- Patch at [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01398.html
[Bug libgomp/65589] OpenMP 3.1 produces random results for simple array copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65589 --- Comment #7 from felix.ospald at gmx dot de --- (In reply to Andrew Pinski from comment #6) > I ran for 2836 iterations with the trunk GCC and aarch64 which has a very > weak memory ordering and did not run into a single failure. This is what I would expect for such a simple application. I currently don't know if this is a hardware or software related issue (I suspect software). Probably there is some misconfiguration in the system. I don't know and I also don't known how to find out. I also don't have admin rights. The strage thing is that the value is 0.5 i.e. 1 (or some gibberish) was not assigned to the location. Is it somehow possible that the corresponding thread was exited (e.g. by some service to limit user ressource usage) before the assignment without any notice from OpenMP? However if I remove the "return 1" sometimes there are several unassigned values in a row and the next iteration might work again without error (which would mean that the thread was recreated). As far as I can tell gcc was installed by the SuSE packagamanager and by updates. I don't think there was much configuration by the admin. Also the version is not too old, wich means it could possibly affect many users. On the other hand I don't know if there are any limitations regarding the number of threads in these precompiled packages? Also I'm not sure if this SuSE PREEMPT desktop version is suitable for such server?
[Bug c++/64666] gcc wrongly accepts assignment in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64666 --- Comment #5 from Harald van Dijk --- (In reply to Jakub Jelinek from comment #4) > Just use -pedantic-errors if you want strict language conformance? -std=* -pedantic is supposed to be enough to get GCC to conform to the specified standard (the standards pretty much never require an error), but anyway, even with -std=c++14 -pedantic-errors, no message at all is given for the program in my earlier comment.
[Bug target/65561] avx512fintrin.h:5344:1: internal compiler error: in curr_insn_transform, at lra-constraints.c:3494
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65561 --- Comment #6 from uros at gcc dot gnu.org --- Author: uros Date: Thu Mar 26 20:37:53 2015 New Revision: 221709 URL: https://gcc.gnu.org/viewcvs?rev=221709&root=gcc&view=rev Log: PR target/65561 * config/i386/sse.md (avx512dq_vextract64x2_1_maskm): Check operand 4 and operand 0 for equality. (avx512f_vextract32x4_1_maskm): Check operand 6 and operand 0 for equality. (vec_extract_lo__maskm): Check operand 2 and operand 0 for equality. (vec_extract_hi__maskm): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md
[Bug c++/64666] gcc wrongly accepts assignment in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64666 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Just use -pedantic-errors if you want strict language conformance?
[Bug target/65576] ICE in gcc.c-torture/compile/pr33855.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65576 --- Comment #2 from Martin Sebor --- *** Bug 65577 has been marked as a duplicate of this bug. ***
[Bug c++/64666] gcc wrongly accepts assignment in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64666
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #3 from Harald van Dijk ---
Strictly speaking, this affects conformance because it causes GCC to wrongly
accept code without any diagnostic, in conforming modes (e.g. -std=c++14
-pedantic), where the standard requires a diagnostic for the syntax error:
struct S { constexpr int operator=(int) { return 1; } };
int main() { int a[S() = 1]; }
Sun C++ and Intel also accept it without any diagnostic. clang rejects it as a
syntax error.
Rejecting it as a syntax error when it was previously accepted seems like a bad
idea, though. Perhaps an extra warning if -pedantic is used would be
appropriate?
[Bug target/65577] ICE on g++.dg/torture/pr58369.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65577 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Martin Sebor --- Both this and pr65576 are caused by the same commit. Closing as duplicate. *** This bug has been marked as a duplicate of bug 65576 ***
[Bug target/65577] ICE on g++.dg/torture/pr58369.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65577 --- Comment #1 from Martin Sebor --- According to git bisect, 2d5ee2b9035db2414ae3535db18550c1d90e52fd is the first bad commit: commit 2d5ee2b9035db2414ae3535db18550c1d90e52fd Author: meissner Date: Thu Mar 19 22:37:33 2015 + [gcc] 2015-03-19 Michael Meissner PR target/65240 * config/rs6000/predicates.md (easy_fp_constant): Remove special -ffast-math handling that kept non-0 constants live in the RTL until reload. Remove logic testing the number of instructions it took to create a constant in a GPR that was never used, due to a test for soft-float earlier. (memory_fp_constant): Delete, no longer used. * config/rs6000/rs6000.md (mov_hardfloat): Remove alternatives for loading non-0 constants into GPRs for hard floating point that is no longer needed due to changes in easy_fp_constant. Add support for loading 0.0 into GPRs. (mov_hardfloat32): Likewise. (mov_hardfloat64): Likewise. (mov_64bit_dm): Likewise. (movtd_64bit_nodm): Likewise. (pre-reload move FP constant define_split): Delete define_split, since it is no longer used. (extenddftf2_internal): Remove GHF constraints that are not valid for extenddftf2. [gcc/testsuite] 2015-03-19 Michael Meissner PR target/65240 * gcc/testsuite/g++.dg/pr65240.h: Add tests for PR 65240. * gcc/testsuite/g++.dg/pr65240-1.C: Likewise. * gcc/testsuite/g++.dg/pr65240-2.C: Likewise. * gcc/testsuite/g++.dg/pr65240-3.C: Likewise. * gcc/testsuite/g++.dg/pr65240-4.C: Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@221524 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug c++/65591] New: G++ should use default constructor for {}-init when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65591
Bug ID: 65591
Summary: G++ should use default constructor for {}-init when
possible
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason at gcc dot gnu.org
CC: daniel.kruegler at googlemail dot com, jakub at gcc dot
gnu.org,
jason at gcc dot gnu.org, maltsevm at gmail dot com,
mpolacek at gcc dot gnu.org, pinskia at gcc dot gnu.org
Depends on: 65154
>From Mikhail Maltsev's comment 5 on Bug #65154:
But it reveals some latent bug (PR65503). In the following case (after applying
the patch):
struct ss {
ss() {};
};
struct C {
ss s[1000];
};
int main() {
C cs[5]{};
}
We'll get 1000 calls to ss() in main instead of calling default c-tor of struct
C. (which is probably not what we want).
-
I agree that we want to call the default constructor in this case, and let the
inliner decide from there. This is not the same issue as bug 65503.
[Bug c++/65154] [4.8/4.9/5 Regression] ICE with {} initialized array with string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65154 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|4.8.5 |4.9.3 --- Comment #9 from Jason Merrill --- Fixed for 4.9.3/5.
[Bug libstdc++/58038] std::this_thread::sleep_until can cause inifinite sleep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58038 --- Comment #13 from Matthew Lai --- (In reply to Jonathan Wakely from comment #11) > (In reply to Matthew Lai from comment #8) > > Here is another case where this bug caused a hard-to-find problem - > > http://stackoverflow.com/questions/17574287/boostthread-attributes-setting- > > call-stack-size > > > > (last comment) > > That seems to be about Boost.Thread so nothing to do with us. Yeah that's in Boost, but it's the exact same bug in Boost. I linked it just to show the kind of problem this can cause. And thanks for the fix!
[Bug libgomp/65589] OpenMP 3.1 produces random results for simple array copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65589 --- Comment #6 from Andrew Pinski --- I ran for 2836 iterations with the trunk GCC and aarch64 which has a very weak memory ordering and did not run into a single failure.
[Bug libstdc++/65500] [5 Regression] FAIL: 17_intro/headers/c++2014/all_attributes.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65500 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug libstdc++/65147] alignment of std::atomic object is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65147 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #6 from Jonathan Wakely --- Fixed for gcc5.
[Bug libstdc++/62259] atomic class doesn't enforce required alignment on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62259 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #7 from Jonathan Wakely --- Fixed for gcc5.
[Bug libstdc++/60421] std::this_thread::sleep_for doesn't sleep for all arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60421 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed for gcc5.
[Bug libstdc++/58038] std::this_thread::sleep_until can cause inifinite sleep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58038 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jonathan Wakely --- Fixed for gcc5.
[Bug libstdc++/58038] std::this_thread::sleep_until can cause inifinite sleep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58038 --- Comment #11 from Jonathan Wakely --- (In reply to Matthew Lai from comment #8) > Here is another case where this bug caused a hard-to-find problem - > http://stackoverflow.com/questions/17574287/boostthread-attributes-setting- > call-stack-size > > (last comment) That seems to be about Boost.Thread so nothing to do with us.
[Bug libstdc++/60421] std::this_thread::sleep_for doesn't sleep for all arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60421 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Thu Mar 26 19:59:08 2015 New Revision: 221708 URL: https://gcc.gnu.org/viewcvs?rev=221708&root=gcc&view=rev Log: PR libstdc++/58038 PR libstdc++/60421 * include/std/thread (this_thread::sleep_for): Check for negative durations. (this_thread::sleep_until): Check for times in the past. * testsuite/30_threads/this_thread/58038.cc: New. * testsuite/30_threads/this_thread/60421.cc: New. Added: trunk/libstdc++-v3/testsuite/30_threads/this_thread/58038.cc trunk/libstdc++-v3/testsuite/30_threads/this_thread/60421.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/thread
[Bug libstdc++/58038] std::this_thread::sleep_until can cause inifinite sleep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58038 --- Comment #10 from Jonathan Wakely --- Author: redi Date: Thu Mar 26 19:59:08 2015 New Revision: 221708 URL: https://gcc.gnu.org/viewcvs?rev=221708&root=gcc&view=rev Log: PR libstdc++/58038 PR libstdc++/60421 * include/std/thread (this_thread::sleep_for): Check for negative durations. (this_thread::sleep_until): Check for times in the past. * testsuite/30_threads/this_thread/58038.cc: New. * testsuite/30_threads/this_thread/60421.cc: New. Added: trunk/libstdc++-v3/testsuite/30_threads/this_thread/58038.cc trunk/libstdc++-v3/testsuite/30_threads/this_thread/60421.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/thread
[Bug c++/65154] [4.8/4.9/5 Regression] ICE with {} initialized array with string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65154 --- Comment #7 from Jason Merrill --- Author: jason Date: Thu Mar 26 19:51:58 2015 New Revision: 221704 URL: https://gcc.gnu.org/viewcvs?rev=221704&root=gcc&view=rev Log: PR c++/65154 * init.c (build_vec_init): Fix initializing aggregates with empty init list. Added: trunk/gcc/testsuite/g++.dg/init/array39.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c
[Bug c++/65154] [4.8/4.9/5 Regression] ICE with {} initialized array with string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65154 --- Comment #8 from Jason Merrill --- Author: jason Date: Thu Mar 26 19:52:00 2015 New Revision: 221705 URL: https://gcc.gnu.org/viewcvs?rev=221705&root=gcc&view=rev Log: PR c++/65154 * init.c (build_vec_init): Fix initializing aggregates with empty init list. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/init/array39.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/init.c
[Bug lto/65588] lto1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65588 David Kredba changed: What|Removed |Added Attachment #35154|0 |1 is obsolete|| --- Comment #2 from David Kredba --- Created attachment 35155 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35155&action=edit A little more c-reduced preprocessed file
[Bug pch/61250] Random pch failures on x86_64-apple-darwin1(3|4).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 --- Comment #14 from howarth at bromo dot med.uc.edu --- Testing https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01334.html in case correction of the overflow tests eliminates this bug.
[Bug libstdc++/62259] atomic class doesn't enforce required alignment on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62259 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Thu Mar 26 19:27:02 2015 New Revision: 221703 URL: https://gcc.gnu.org/viewcvs?rev=221703&root=gcc&view=rev Log: PR libstdc++/62259 PR libstdc++/65147 * include/std/atomic (atomic): Increase alignment for types with the same size as one of the integral types. * testsuite/29_atomics/atomic/60695.cc: Adjust dg-error line number. * testsuite/29_atomics/atomic/62259.cc: New. Added: trunk/libstdc++-v3/testsuite/29_atomics/atomic/62259.cc - copied, changed from r221701, trunk/libstdc++-v3/testsuite/29_atomics/atomic/60695.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/atomic trunk/libstdc++-v3/testsuite/29_atomics/atomic/60695.cc
[Bug fortran/65590] New: FAIL: gfortran.dg/coarray/coindexed_3.f90 -fcoarray=single -O2 -latomic (test for errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65590 Bug ID: 65590 Summary: FAIL: gfortran.dg/coarray/coindexed_3.f90 -fcoarray=single -O2 -latomic (test for errors) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 spawn /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran -B/test/gnu/gcc /objdir/gcc/testsuite/gfortran/../../ -B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11 /./libgfortran/ /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/coarray/coindexed_3. f90 -fno-diagnostics-show-caret -fdiagnostics-color=never -fcoarray=single -O2 - latomic -S -o coindexed_3.s FAIL: gfortran.dg/coarray/coindexed_3.f90 -fcoarray=single -O2 -latomic (test for errors, line 49) FAIL: gfortran.dg/coarray/coindexed_3.f90 -fcoarray=single -O2 -latomic (test for errors, line 60) PASS: gfortran.dg/coarray/coindexed_3.f90 -fcoarray=single -O2 -latomic (test for excess errors)
[Bug libstdc++/65147] alignment of std::atomic object is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65147 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Thu Mar 26 19:27:02 2015 New Revision: 221703 URL: https://gcc.gnu.org/viewcvs?rev=221703&root=gcc&view=rev Log: PR libstdc++/62259 PR libstdc++/65147 * include/std/atomic (atomic): Increase alignment for types with the same size as one of the integral types. * testsuite/29_atomics/atomic/60695.cc: Adjust dg-error line number. * testsuite/29_atomics/atomic/62259.cc: New. Added: trunk/libstdc++-v3/testsuite/29_atomics/atomic/62259.cc - copied, changed from r221701, trunk/libstdc++-v3/testsuite/29_atomics/atomic/60695.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/atomic trunk/libstdc++-v3/testsuite/29_atomics/atomic/60695.cc
[Bug tree-optimization/65551] [5 Regression] FAIL: 26_numerics/complex/50880.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65551 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug pch/61250] Random pch failures on x86_64-apple-darwin1(3|4).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250
--- Comment #13 from howarth at bromo dot med.uc.edu ---
The offending line appears to be at...
static const struct line_map*
linemap_macro_map_lookup (struct line_maps *set, source_location line)
{
unsigned int md, mn, mx;
const struct line_map *cached, *result;
if (IS_ADHOC_LOC (line))
line = set->location_adhoc_data_map.data[line & MAX_SOURCE_LOCATION].locus;
linemap_assert (line >= LINEMAPS_MACRO_LOWEST_LOCATION (set)); <=
[Bug tree-optimization/65551] [5 Regression] FAIL: 26_numerics/complex/50880.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65551 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Thu Mar 26 19:17:44 2015 New Revision: 221702 URL: https://gcc.gnu.org/viewcvs?rev=221702&root=gcc&view=rev Log: PR tree-optimization/65551 * tree-ssa-sccvn.c (fully_constant_vn_reference_p): Use TYPE_PRECISION only for INTEGRAL_TYPE_P types. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug pch/61250] Random pch failures on x86_64-apple-darwin1(3|4).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250
--- Comment #12 from howarth at bromo dot med.uc.edu ---
To clarify, I am able to debug the core file by executing...
make -k -j8 check RUNTESTFLAGS="pch.exp=pch.C --target_board=unix'{-dH}'"
until I see...
FAIL: g++.dg/pch/pch.C -O2 -I. -Dwith_PCH (internal compiler error)
FAIL: g++.dg/pch/pch.C -O2 -I. -Dwith_PCH (test for excess errors)
FAIL: g++.dg/pch/pch.C -O2 assembly comparison
at which time I find the expected core file added to /cores for use with...
gdb /sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/gcc/cc1plus /cores/core.4746
which uniformly shows...
#0 0x7fff96238286 in __pthread_kill ()
#1 0x7fff9488042f in pthread_kill ()
#2 0x7fff8e9c1b53 in abort ()
#3 0x000100f31530 in linemap_lookup (set=0x1017590f0, line=523) at
../../gcc-5-20150325/libcpp/line-map.c:763
[Bug pch/61250] Random pch failures on x86_64-apple-darwin1(3|4).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 --- Comment #11 from howarth at bromo dot med.uc.edu --- It appears that -dH does indeed produce a core in /cores. Using... gdb /sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/gcc/cc1plus /cores/core.92484 the bt shows... #0 0x7fff96238286 in __pthread_kill () #1 0x7fff9488042f in pthread_kill () #2 0x7fff8e9c1b53 in abort () #3 0x000100f31530 in linemap_lookup (set=0x10175d000, line=651) at ../../gcc-5-20150325/libcpp/line-map.c:763
[Bug target/44685] internal compiler error: in final_scan_insn, at final.c:2650 while compiling program with complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44685 --- Comment #3 from David Binderman --- (In reply to David Binderman from comment #2) > I am getting something similar on blackfin > when building linux kernel > arch/blackfin/kernel/setup.c:1110:1: internal compiler error: in > final_scan_insn, at final.c:2952 Still getting it a few months later, with a gcc 492 cross compiler.
[Bug target/65576] ICE in gcc.c-torture/compile/pr33855.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65576 --- Comment #1 from Martin Sebor --- git bisect pinpointed the following as the commit that introduced the ICE: commit 2d5ee2b9035db2414ae3535db18550c1d90e52fd Author: meissner Date: Thu Mar 19 22:37:33 2015 + [gcc] 2015-03-19 Michael Meissner PR target/65240 * config/rs6000/predicates.md (easy_fp_constant): Remove special -ffast-math handling that kept non-0 constants live in the RTL until reload. Remove logic testing the number of instructions it took to create a constant in a GPR that was never used, due to a test for soft-float earlier. (memory_fp_constant): Delete, no longer used. * config/rs6000/rs6000.md (mov_hardfloat): Remove alternatives for loading non-0 constants into GPRs for hard floating point that is no longer needed due to changes in easy_fp_constant. Add support for loading 0.0 into GPRs. (mov_hardfloat32): Likewise. (mov_hardfloat64): Likewise. (mov_64bit_dm): Likewise. (movtd_64bit_nodm): Likewise. (pre-reload move FP constant define_split): Delete define_split, since it is no longer used. (extenddftf2_internal): Remove GHF constraints that are not valid for extenddftf2. [gcc/testsuite] 2015-03-19 Michael Meissner PR target/65240 * gcc/testsuite/g++.dg/pr65240.h: Add tests for PR 65240. * gcc/testsuite/g++.dg/pr65240-1.C: Likewise. * gcc/testsuite/g++.dg/pr65240-2.C: Likewise. * gcc/testsuite/g++.dg/pr65240-3.C: Likewise. * gcc/testsuite/g++.dg/pr65240-4.C: Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@221524 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug pch/61250] Random pch failures on x86_64-apple-darwin1(3|4).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 --- Comment #10 from howarth at bromo dot med.uc.edu --- The crashing compiler does leave a crash log in ~/Library/Logs/DiagnosticReports but unfortunately these show... Backtrace not available
[Bug libgomp/65589] OpenMP 3.1 produces random results for simple array copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65589 --- Comment #5 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #3) > Note rand () is not thread-safe, so calling it from multiple threads > concurrently is undefined-behavior. Actually looking into glibc sources, you can notice there is a lock inside __random code. And this comment in the sources: /* POSIX.1c requires that there is mutual exclusion for the `rand' and `srand' functions to prevent concurrent calls from modifying common data. */ But everywhere else says rand is not thread safe.
[Bug libgomp/65589] OpenMP 3.1 produces random results for simple array copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65589 --- Comment #4 from felix.ospald at gmx dot de --- (In reply to Jakub Jelinek from comment #3) > Can't reproduce here, with neither 4.8 nor 4.9. But tested just on 16 > threads box (both with argument 16 and 32). With only 16 threads I also cannot reproduce the error (I think it is just more unlikely that somehow two threads infere). Also it sometimes takes several tries to reproduce the error. > Note rand () is not thread-safe, so calling it from multiple threads > concurrently is undefined-behavior. Yes I know, but I can reprodce the error also with the omp critical pragma, but it takes longer. > > Haven't spotted anything wrong in the generated code. Thank you. I will compile the trunk version and try again.
[Bug pch/61250] Random pch failures on x86_64-apple-darwin1(3|4).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 --- Comment #9 from howarth at bromo dot med.uc.edu --- Unfortunately it doesn't look like the -d option... `H' Produce a core dump whenever an error occurs. is functional on darwin.
[Bug libgomp/65589] OpenMP 3.1 produces random results for simple array copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65589 --- Comment #3 from Jakub Jelinek --- Can't reproduce here, with neither 4.8 nor 4.9. But tested just on 16 threads box (both with argument 16 and 32). Note rand () is not thread-safe, so calling it from multiple threads concurrently is undefined-behavior. Haven't spotted anything wrong in the generated code.
[Bug libgomp/65589] OpenMP 3.1 produces random results for simple array copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65589 --- Comment #2 from felix.ospald at gmx dot de --- (In reply to Andrew Pinski from comment #1) > I cannot reproduce this on an AARCH64 target with 48 cores with the trunk. I do not have the trunk installed. What do you suggest? Should I compile my own libgomp? This program is an extract of an larger project. Currently this blocks everything and it probably cost my more than a week to realize this problem.
[Bug target/65561] avx512fintrin.h:5344:1: internal compiler error: in curr_insn_transform, at lra-constraints.c:3494
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65561 --- Comment #5 from Rainer Emrich --- (In reply to Uroš Bizjak from comment #3) > Rainer, the failure doesn't trigger for me on crosscompiler from > x86_64-linux-gnu. Can you please check if the attached patch fixes the > failure for you? ICE is gone.
[Bug libgomp/65589] OpenMP 3.1 produces random results for simple array copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65589 --- Comment #1 from Andrew Pinski --- I cannot reproduce this on an AARCH64 target with 48 cores with the trunk.
[Bug pch/61250] Random pch failures on x86_64-apple-darwin1(3|4).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 --- Comment #8 from howarth at bromo dot med.uc.edu --- I also noticed that the ICE... FAIL: g++.dg/pch/pch.C -O2 -g -I. -Dwith_PCH (internal compiler error) FAIL: g++.dg/pch/pch.C -O2 -g -I. -Dwith_PCH (test for excess errors) FAIL: g++.dg/pch/pch.C -O2 -g assembly comparison doesn't seem to produce a log for the crashing compiler in ~/Library/Logs/CrashReporter whereas the crashing testcase executables do. Is there a trick to building the compiler so that when it crashes a CrashLog will be produced?
[Bug libstdc++/65033] C++11 atomics: is_lock_free result does not always match the real lock-free property
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65033 Richard Henderson changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #8 from Richard Henderson --- Fixed.
[Bug libstdc++/65033] C++11 atomics: is_lock_free result does not always match the real lock-free property
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65033 --- Comment #7 from Richard Henderson --- Author: rth Date: Thu Mar 26 18:31:11 2015 New Revision: 221701 URL: https://gcc.gnu.org/viewcvs?rev=221701&root=gcc&view=rev Log: PR libstdc++/65033 * include/bits/atomic_base.h (__atomic_base::is_lock_free): Build a fake pointer indicating type alignment. (__atomic_base::is_lock_free): Likewise. * include/std/atomic (atomic::is_lock_free): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/atomic_base.h trunk/libstdc++-v3/include/std/atomic
[Bug pch/61250] Random pch failures on x86_64-apple-darwin1(3|4).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 --- Comment #7 from howarth at bromo dot med.uc.edu --- Is there any sensible approach we can use to try to obtain a backtrace?
[Bug c++/65154] [4.8/4.9/5 Regression] ICE with {} initialized array with string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65154
--- Comment #6 from Jason Merrill ---
(In reply to Mikhail Maltsev from comment #5)
> We'll get 1000 calls to ss() in main instead of calling default c-tor of
> struct C. (which is probably not what we want).
Agreed, we ought to use the default constructor for {}-initialization when we
can.
[Bug c++/65503] g++ string array in struct crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65503
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-03-26
CC||jason at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Jason Merrill ---
(In reply to Mikhail Maltsev from comment #2)
> Also, I noticed that in some cases GCC is able to generate a loop for
> initialization:
>
> #include
>
> int main() {
> std::string m[1000] {"x", "y"};
> std::string n[1000] = {"x", "y"};
> }
>
> That is done in cp/init.c:build_vec_init. But for the original testcase, the
> loop is not created. Is it a bug?
It's a poor optimization choice; we ought to build a loop for member array
initialization as well as array variables.
[Bug libgomp/65589] OpenMP 3.1 produces random results for simple array copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65589 Andrew Pinski changed: What|Removed |Added Version|unknown |4.8.1 Severity|blocker |normal
[Bug libgomp/65589] New: OpenMP 3.1 produces random results for simple array copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65589
Bug ID: 65589
Summary: OpenMP 3.1 produces random results for simple array
copy
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: felix.ospald at gmx dot de
CC: jakub at gcc dot gnu.org
/*
gcc --version
gcc (SUSE Linux) 4.8.1 20130909 [gcc-4_8-branch revision 202388]
echo | cpp -fopenmp -dM | grep -i open
#define _OPENMP 201107
cat /proc/version
Linux version 3.11.10-17-desktop (geeko@buildhost) (gcc version 4.8.1 20130909
[gcc-4_8-branch revision 202388] (SUSE Linux) ) #1 SMP PREEMPT Mon Jun 16
15:28:13 UTC 2014 (fba7c1f)
cat /proc/meminfo
MemTotal: 529410640 kB
lsb_release -a
LSB Version:
core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64:desktop-4.0-amd64:desktop-4.0-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.2-amd64:graphics-3.2-noarch:graphics-4.0-amd64:graphics-4.0-noarch
Distributor ID: openSUSE project
Description:openSUSE 13.1 (Bottle) (x86_64)
Release:13.1
Codename: Bottle
lscpu
Architecture: x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):64
On-line CPU(s) list: 0-63
Thread(s) per core:2
Core(s) per socket:8
Socket(s): 4
NUMA node(s): 4
Vendor ID: GenuineIntel
CPU family:6
Model: 45
Model name:Intel(R) Xeon(R) CPU E5-4640 0 @ 2.40GHz
Stepping: 7
CPU MHz: 2712.000
BogoMIPS: 4815.64
Virtualization:VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 20480K
NUMA node0 CPU(s): 0-7,32-39
NUMA node1 CPU(s): 8-15,40-47
NUMA node2 CPU(s): 16-23,48-55
NUMA node3 CPU(s): 24-31,56-63
Running this program results in an output like
loop 0
loop 1
loop 2
loop 3
loop 4
loop 5
loop 6
loop 7
loop 8
fault index=716440 value=0.5
So it seems like that the value at index 716440 is never set to 1.
Sometimes several attempts (ctrl+C and run again) and sometimes several
hundered loops are required until the error occurs.
This error rarely occurs when run with less than 32 threads (never on 1 core).
The "rand()" function is called because it seems to make the error occour more
often (but it also occurs without this line).
In general code wich produces different runtime on each thread seems to make
the error occour more often. The "rand()" function seems to have internal
thread locking, wich casuses different delays for each thread.
The error was reproduced on two different machines (so bad memory is unlikely,
however both run the same os+gcc versions).
The following things do not have any influence:
- gcc optimization swich -O0
- gcc -march switch (native or x86-64)
- #pragma omp flush (at various places)
- schedule static/dynamic
- catching exceptions inside the loop
I have no clue what is going on. Any help is very appreciated.
*/
#include
#include
#include
#include
int main(int argc, char* argv[])
{
int num_threads = omp_get_num_procs();
if (argc > 1) {
num_threads = atoi(argv[1]);
}
omp_set_dynamic(0);
omp_set_nested(0);
omp_set_num_threads(num_threads);
std::cout << "num_threads=" << omp_get_max_threads() << std::endl;
const int n = 512*512*4;
double* phi0 = new double[n];
double* sigma0 = new double[n];
for (int iter = 0;; iter++)
{
std::cout << "loop " << iter << std::endl;
for (int k = 0; k < n; k++)
{
phi0[k] = 1;
sigma0[k] = 0.5;
}
#pragma omp parallel for schedule(static)
for (int i = 0; i < n; i++)
{
//#pragma omp critical
rand();
sigma0[i] = phi0[i];
}
for (int j = 0; j < n; j++)
{
if (sigma0[j] != 1) {
std::cout << "fault index=" << j << " value=" << sigma0[j] <<
std::endl;
return 1;
}
}
}
return 0;
}
The CMakeLists.txt:
cmake_minimum_required(VERSION 2.8)
SET(CMAKE_BUILD_TYPE Release)
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -march=native -O2 -fopenmp")
#SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -march=x86-64 -mtune=generic -O0
-fopenmp -fstack-check -fbounds-check")
SET(SOURCES main.cpp)
ADD_EXECUTABLE(main ${SOURCES})
[Bug c++/65525] [5 Regression] ICE: sorry, unimplemented: unexpected AST of kind mem_ref (-std=c++14, ICE: in potential_constant_expression_1, at cp/constexpr.c:4432)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65525 --- Comment #6 from Jason Merrill --- Author: jason Date: Thu Mar 26 17:58:39 2015 New Revision: 221699 URL: https://gcc.gnu.org/viewcvs?rev=221699&root=gcc&view=rev Log: PR c++/65525 * constexpr.c (potential_constant_expression_1): Handle MEM_REF. Added: trunk/gcc/testsuite/g++.dg/parse/assign1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug c++/65525] [5 Regression] ICE: sorry, unimplemented: unexpected AST of kind mem_ref (-std=c++14, ICE: in potential_constant_expression_1, at cp/constexpr.c:4432)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65525 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #5 from Jason Merrill --- Fixed.
[Bug go/65587] C package incomplete/not working for powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65587 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Ian Lance Taylor --- Should be fixed. Thanks for the attachments.
[Bug go/65587] C package incomplete/not working for powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65587 --- Comment #4 from ian at gcc dot gnu.org --- Author: ian Date: Thu Mar 26 17:51:57 2015 New Revision: 221698 URL: https://gcc.gnu.org/viewcvs?rev=221698&root=gcc&view=rev Log: PR go/65587 debug/elf: apply relocations for SHT_RELA/EM_PPC Modified: trunk/libgo/go/debug/elf/file.go
[Bug pch/61250] Random pch failures on x86_64-apple-darwin1(3|4).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 --- Comment #6 from Dominique d'Humieres --- > Does the -Winvalid-pch flag give any extra information? AFAICT no.
[Bug lto/65588] lto1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65588 --- Comment #1 from David Kredba --- Created attachment 35154 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35154&action=edit A little c-reduced preprocessed file
[Bug go/65587] C package incomplete/not working for powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65587 --- Comment #3 from Matthias Klose --- Created attachment 35153 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35153&action=edit object file
[Bug pch/61250] Random pch failures on x86_64-apple-darwin1(3|4).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #5 from Eric Gallager --- Does the -Winvalid-pch flag give any extra information?
[Bug lto/65588] New: lto1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65588
Bug ID: 65588
Summary: lto1: internal compiler error: Segmentation fault
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: nheghathivhistha at gmail dot com
Created attachment 35152
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35152&action=edit
Preprocessed source file gzipped
Gcc trunk revision 221643 ICEs during Lisp package compilation.
LANG=C LC_ALL=C gcc -flto=4 -fuse-linker-plugin -O2 -g -pipe -march=core2
-mtune=core2 -Wa,--noexecstack -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit
-Wreturn-type -Wmissing-declarations -Wno-sign-compare -Wno-format-nonliteral
-O -falign-functions=4 -pthread -DENABLE_UNICODE -DMULTITHREAD -DPOSIX_THREADS
-DDYNAMIC_FFI -I. -Wl,-flto -fuse-linker-plugin -Wl,--as-needed -Wl,-O2
-Wl,--sort-common -Wl,--hash-style=gnu -O2 -g -pipe -march=core2 -mtune=core2
spvw.i -r -nostdlib
In file included from ../src/spvw.d:927:0:
../src/spvw_garcol.d: In function 'fill_varobject_heap_holes':
../src/spvw_garcol.d:1764:15: warning: comparison is always false due to
limited range of data type [-Wtype-limits]
if (len > arraysize_limit_1) {
^
../src/spvw.d: In function 'main_actions':
../src/spvw.d:3487:36: warning: variable 'fileptr' might be clobbered by
'longjmp' or 'vfork' [-Wclobbered]
var const argv_compile_file_t* fileptr = &p->argv_compile_files[0];
^
../src/spvw.d:3488:15: warning: variable 'count' might be clobbered by
'longjmp' or 'vfork' [-Wclobbered]
var uintL count = p->argv_compile_filecount;
^
../src/spvw.d:3469:13: warning: variable 'count' might be clobbered by
'longjmp' or 'vfork' [-Wclobbered]
var uintL count = p->argv_init_filecount;
^
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug go/65587] C package incomplete/not working for powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65587 --- Comment #2 from Matthias Klose --- Created attachment 35151 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35151&action=edit output of cgo command
[Bug lto/65536] LTO line number information garbled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 --- Comment #45 from Manuel López-Ibáñez --- (In reply to Jan Hubicka from comment #42) > Hi, > I read linemap_line_start and I think I noticed few issues with respect > to overflows and lines being added randomly. I honestly think this is too sensitive for stage3. I'm also not very much in favour for optimizing out-of-order creating of line-maps. That is not the typical case outside LTO and I would argue it should not be the typical case in LTO either. Of course, fixing overflow problems is orthogonal and desirable and should be submitted as a separate patch. > 1) line_delta is computed as to_line SOURCE_LINE (map, set->highest_line) >I think the last inserted line is not very releavnt. What we care about > is >the base of the last location and to keep thing dense how much we are >stretching the value range from highest inserted element (inserting into > middle >is cheap). My guess is that the motivation here is that, if there is a large gap, it means that we didn't get asked any source_location since a lot of lines ago. thus it would save a lot of source_locations to simply start a new map now. Of course, this does not work for out-of-order, but why should we pessimize typical usage for something that should be fixed in LTO? > 2) (line_delta > 10 && line_delta * ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) > > 1000) >ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) is in range 7... 15, so it never >gets high enough to make this conditional trigger. I changed it to: I don't understand this. A line_delta of 67 (1000/15) will already trigger it. > 4) the code deciding whether to do reuse seems worng: > if (line_delta < 0 > || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map) > || SOURCE_COLUMN (map, highest) >= (1U << column_bits)) > >line_delta really should be base_line_delta, we do not need to give up >when map's line is 1, SOURCE_LINE (map, set->highest_line) is 5 >and we are requested to switch to line 3. If you insert a line out of order without creating a new map, then linemap_position_for_column will return the wrong value.
[Bug go/65587] C package incomplete/not working for powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65587 --- Comment #1 from Ian Lance Taylor --- When I've seen this before, it's been because the relocation processing in applyRelocationsPPC in debug/elf/file.go is not working. If you run the go command with the -x option, you will see the exact command that is failing. It will be the cgo command. If you run the cgo command with the -debug-gcc option you will see that it fails after compiling a program. Please compile that program with your powerpc-linux-gnu compiler and attach the object file here. Thanks.
[Bug go/65587] New: C package incomplete/not working for powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65587 Bug ID: 65587 Summary: C package incomplete/not working for powerpc-linux-gnu Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: doko at gcc dot gnu.org CC: cmang at google dot com when trying to build github.com/gosexy/gettext/gettext.go on powerpc-linux-gnu, I get dist/src/github.com/gosexy/gettext/gettext.go:42:16: unable to find value of constant C.LC_ALL dist/src/github.com/gosexy/gettext/gettext.go:46:19: unable to find value of constant C.LC_ALL dist/src/github.com/gosexy/gettext/gettext.go:50:18: unable to find value of constant C.LC_CTYPE dist/src/github.com/gosexy/gettext/gettext.go:53:21: unable to find value of constant C.LC_MESSAGES dist/src/github.com/gosexy/gettext/gettext.go:56:21: unable to find value of constant C.LC_MONETARY dist/src/github.com/gosexy/gettext/gettext.go:60:20: unable to find value of constant C.LC_NUMERIC dist/src/github.com/gosexy/gettext/gettext.go:63:17: unable to find value of constant C.LC_TIME dist/src/github.com/gosexy/gettext/gettext.go:68:13: call of non-function C.CString dist/src/github.com/gosexy/gettext/gettext.go:70:9: call of non-function C.GoString dist/src/github.com/gosexy/gettext/gettext.go:70:20: call of non-function C.setlocale panic: runtime error: invalid memory address or nil pointer dereference [signal 0xb code=0x1 addr=0x14] goroutine 16 [running]: main.rewriteRef.pN12_main.Package ../../src/gotools/../libgo/go/cmd/cgo/gcc.go:620 main.Translate.pN12_main.Package ../../src/gotools/../libgo/go/cmd/cgo/gcc.go:184 main.main ../../src/gotools/../libgo/go/cmd/cgo/main.go:287 created by main ../../../src/libgo/runtime/go-main.c:42 goroutine 18 [finalizer wait]:
[Bug c/65586] -fopenmp-simd rejects valid input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65586 Tobias Burnus changed: What|Removed |Added Summary|[5 Regression] |-fopenmp-simd rejects valid |-fopenmp-simd rejects valid |input |input | --- Comment #1 from Tobias Burnus --- I retraced the regression status: It doesn't seem to compile with GCC 4.9, either. And I don't know whether it worked with those options before in 5 - I think I either had both enabled (and optimization) or neither (with -O0 for debugging.)
[Bug c/65586] New: [5 Regression] -fopenmp-simd rejects valid input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65586
Bug ID: 65586
Summary: [5 Regression] -fopenmp-simd rejects valid input
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: openmp, rejects-valid
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
One of the recent GCC changes causes -fopenmp-simd to reject code, which
compiled before (by ignoring it):
gcc -fno-openmp -fopenmp-simd foo.c
foo.c: In function ‘main’:
foo.c:4:17: error: expected end of line before ‘collapse’
#pragma omp for collapse(1)
^
void foo() { }
int main() {
#pragma omp for collapse(1)
for (int i = 1; i <= 151; i+=31)
foo();
}
[Bug fortran/65585] Implicit allocation of unallocated array with an implicit summation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65585 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin --- The relevant section in the standard is: 7.2.1.3 Interpretation of intrinsic assignments
[Bug target/65584] [i386] Intrinsics inclusion with `-nostdinc' failing due to `stdlib.h' dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65584 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- IMHO a user error, if you use -nostdinc, you are responsible for letting the compiler know where to find all the needed includes.
[Bug fortran/65585] Implicit allocation of unallocated array with an implicit summation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65585 --- Comment #2 from EatDirt --- Sorry for the noise and thanks very much for the info. I was completely unaware of the f2003 feature!
[Bug fortran/65585] Implicit allocation of unallocated array with an implicit summation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65585 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Dominique d'Humieres --- gfortran is behaving as expected: iamwild is allocated on assignment as stated in the manual -frealloc-lhs An allocatable left-hand side of an intrinsic assignment is automatically (re)allocated if it is either unallocated or has a different shape. The option is enabled by default except when -std=f95 is given. See also -Wrealloc-lhs. Note this apply to full arrays only, hence the segfault if you use iamwild(:) and iamwild unallocated. > PS: took me the day to understand why my code was not working with another > compiler... :-/ If the "other compiler" is ifort, this behavior is not the default and has to be set by some option.
[Bug fortran/65585] New: Implicit allocation of unallocated array with an implicit summation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65585 Bug ID: 65585 Summary: Implicit allocation of unallocated array with an implicit summation Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dirteat at gmail dot com Created attachment 35150 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35150&action=edit 10 lines code reproducing the bug Hi there, I did not find any bug report on this, but the small attached code compiled with gcc-gfortran 4.9.2 implicitely allocate an non-allocated array; or segfault, depending on how the implicit assignement is written. Compiled with: gfortran -c noalloc.f90; gfortran noalloc.o -o bug With the assignemnt written as: iamwild = iamfine I get the following output: Are you fine? 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.000 With the assignment written as: iamwild(:) = iamfine(:) I get the expected behavior: ./bug Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7F8CF04BA597 #1 0x7F8CF04BABAE #2 0x7F8CEF9C66AF #3 0x400BC3 in MAIN__ at noalloc.f90:? Segmentation fault PS: took me the day to understand why my code was not working with another compiler... :-/
[Bug c++/65525] [5 Regression] ICE: sorry, unimplemented: unexpected AST of kind mem_ref (-std=c++14, ICE: in potential_constant_expression_1, at cp/constexpr.c:4432)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65525 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #4 from Jason Merrill --- (In reply to Richard Biener from comment #3) > so I wonder why we look at the side-effects at all? That is, why does > COMPOUND_EXPR handling not return false on side-effects early? Because a call to a constexpr function has TREE_SIDE_EFFECTS; we don't know whether it's constant until we do the evaluation.
[Bug target/65584] New: [i386] Intrinsics inclusion with `-nostdinc' failing due to `stdlib.h' dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65584 Bug ID: 65584 Summary: [i386] Intrinsics inclusion with `-nostdinc' failing due to `stdlib.h' dependency Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kyukhin at gcc dot gnu.org Created attachment 35149 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35149&action=edit Reproducer Hello, When disabling standard headers inclusion, it is impossible to use GCC intrinsics: $ ./release/usr/local/bin/gcc -mavx -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.8.2/include -S repro.c In file included from /usr/lib/gcc/x86_64-redhat-linux/4.8.2/include/xmmintrin.h:38:0, from /usr/lib/gcc/x86_64-redhat-linux/4.8.2/include/x86intrin.h:34, from repro.c:2: /usr/lib/gcc/x86_64-redhat-linux/4.8.2/include/mm_malloc.h:27:20: fatal error: stdlib.h: No such file or directory compilation terminated. This is because `mm_malloc.h' depends on malloc () / free () calls. Maybe remove this dependence?
[Bug rtl-optimization/42575] arm-eabi-gcc 64-bit multiply weirdness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42575 ktkachov at gcc dot gnu.org changed: What|Removed |Added Version|4.2.1 |5.0 --- Comment #15 from ktkachov at gcc dot gnu.org --- Updating version as this still affects trunk
[Bug c++/59256] qualified name in friend function declaration doesn't match previous declaration in inline namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59256
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|jason at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #4 from Jason Merrill ---
A related testcase:
inline namespace A {
void f();
}
class B
{
B();
friend void ::f();
};
void A::f() { B b; }
int main()
{
f();
}
It turns out that friend matching code doesn't support inline namespaces very
thoroughly. set_decl_namespace handles this sort of thing for some cases, but
it punts on templates and then tsubst_friend_function doesn't do anything about
inline namespaces.
But this is too complicated to fix for GCC 5, so I'm unassigning myself.
