[Bug c++/54764] New: In class initialization of non-static lambda member can't be used in class with default template paramer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54764 Bug #: 54764 Summary: In class initialization of non-static lambda member can't be used in class with default template paramer Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: leo...@volnitsky.com Clang-3.2 compiles (FWIW), but rejected by GCC 4.7.1 and 4.8: -- #include template struct c{ std::function f = [](int i){return i+i;}; }; int main() {} --- Error message: t.cc:6:31: error: default argument for template parameter for class enclosing ‘struct __lambda0’ function f = [](int i){return i+i;}; ^
[Bug target/51708] SH Target: SHAD / SHLD constant not CSE-ed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51708 --- Comment #2 from Oleg Endo 2012-09-30 23:11:09 UTC --- In order to 'force' the constant load to be CSE-ed the constant load and dynamic shift patterns have to be emitted in the respective expanders, so that the CSE pass can see the constant load. It would be even better to check whether the shift insn is in a loop when deciding whether to use a dynamic shift insn or not. It is better to convert all non 1/2/8/16 shifts that are buried inside loops to dynamic shifts. If there are enough registers available every shift would become a 1 insn operation.
[Bug target/34777] uClibc-0.9.29 compilation error for sh4 arch with gcc-4.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #6 from Oleg Endo 2012-09-30 22:47:33 UTC --- (In reply to comment #5) > Created attachment 14973 [details] > reduced testcase > I have tried to reproduce the ICE with the reduced testcase on rev 191865 with the following options: -x c -m4 -mb -fschedule-insns -fPIC -mprefergot -x c -m4 -ml -fschedule-insns -fPIC -mprefergot and optimization levels -O0 -O1 -O2 -O3 -Os -Og. It seems the problem does not happen anymore.
[Bug rtl-optimization/11708] [sh4-elf-gcc] Non-Optimal jump code generation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11708 Oleg Endo changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #8 from Oleg Endo 2012-09-30 22:27:32 UTC --- I have checked this issue again on rev 191865 and the problem seems to not happen anymore. I've created a new PR 54762 for the issue in comment #7.
[Bug c++/54763] New: Crash with enable_if (instead of recursive template errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54763 Bug #: 54763 Summary: Crash with enable_if (instead of recursive template errors) Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: pk...@outlook.com Created attachment 28308 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28308 C++11 code which causes an internal compiler error The attached minimised C++11 test case causes an internal compiler error. Clang instead gives an endless list of errors such as: fatal error: recursive template instantiation exceeded maximum depth of 512 The code, which is also shown below, will run correctly if the enable_if is instead set to: std::enable_if<(I>0)>::type. #include template struct tint {}; double zod(tint<0>) { return 3.142; } template < unsigned I, typename = typename std::enable_if<(I>0),decltype(zod(tint()))>::type > decltype(zod(tint())) zod(tint) { return zod(tint()); } int main(int argc, char *argv[]) { zod(tint<0>()); return 0; }
[Bug middle-end/40205] OpenMP do loop with MAXINT gives wrong trip count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40205 --- Comment #3 from Paul Keir 2012-09-30 21:29:22 UTC --- Still present in GFortran 4.7.2 on 32-bit Ubuntu 12.04.1.
[Bug middle-end/54759] [4.8 regression] segfault for gcc.dg/vect/pr49093.c on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54759 --- Comment #2 from Eric Botcazou 2012-09-30 21:22:35 UTC --- > Thanks for reporting the bug. I prepared a patch to fix this: > > http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01997.html > > Could you help verify if it is fixed by this? The segfault disappears once the patch is applied, thanks!
[Bug target/54699] [4.8 Regression] [SH] gfortran.dg/class_array_9.f03 ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54699 --- Comment #3 from Oleg Endo 2012-09-30 21:09:29 UTC --- Doing this... Index: gcc/config/sh/sh.c === --- gcc/config/sh/sh.c(revision 191865) +++ gcc/config/sh/sh.c(working copy) @@ -10079,6 +10079,9 @@ static bool sh_legitimate_address_p (enum machine_mode mode, rtx x, bool strict) { + if (reload_completed) +return true; + if (MAYBE_BASE_REGISTER_RTX_P (x, strict)) return true; else if ((GET_CODE (x) == POST_INC || GET_CODE (x) == PRE_DEC) makes the ICE go away. However, I have not tested this for any other consequences. This one is probably the better fix (max_mov_insn_displacement): Index: gcc/config/sh/sh.c === --- gcc/config/sh/sh.c(revision 191865) +++ gcc/config/sh/sh.c(working copy) @@ -3457,21 +3457,20 @@ /* SH2A supports FPU move insns with 12 bit displacements. Other variants to do not support any kind of displacements for - FPU move insns. */ - if (! consider_sh2a && TARGET_FPU_ANY && GET_MODE_CLASS (mode) == MODE_FLOAT) -return 0; - else -{ - const int mov_insn_sz = mov_insn_size (mode, consider_sh2a); - const int mode_sz = GET_MODE_SIZE (mode); - int r = 15 * mov_insn_sz * disp_scale; + FPU move insns. However, in the worst case, we can still use SImode + loads/stores with displacement, such as in the movsf_ie pattern instead + of true FPU move insns. It's just going to be more expensive because + additional gp reg <-> fpu reg moves have to be used for that. */ + const int mov_insn_sz = mov_insn_size (mode, consider_sh2a); + const int mode_sz = GET_MODE_SIZE (mode); + int r = 15 * mov_insn_sz * disp_scale; - /* If the mov insn will be split into multiple loads/stores, the - maximum possible displacement is a bit smaller. */ - if (mode_sz > mov_insn_sz) -r -= mode_sz - mov_insn_sz; - return r; -} + /* If the mov insn will be split into multiple loads/stores, the + maximum possible displacement is a bit smaller. */ + if (mode_sz > mov_insn_sz) +r -= mode_sz - mov_insn_sz; + + return r; } /* Determine the alignment mask for a move insn of the This makes the ICE go away, but it will wrongly output SH2A fmov.s insns such as fmov.s@(16,r7),fr3 when compiling for SH4. The movsf_ie insn looks a bit ... complicated ... and probably should be split into multiple insns to be able to handle such cases. Maybe there's an even easier solution, but I can't imagine one at the moment.
[Bug libfortran/54736] GFORTRAN_CONVERT_UNIT causes malloc error on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54736 --- Comment #5 from Shane Hart 2012-09-30 20:56:39 UTC --- (In reply to comment #4) > Am 30.09.2012 21:12, schrieb shart6 at utk dot edu: > > If n_elist = 1, then high = low = 0, and the funtion will always return 0, > > even > > if the unit passed in to search for is in the exception list. > > If there are n_elist exceptions, then they can be found in > elist[0], ..., elist[n_elist-1]. > > If there is one exception, then it can be found at elist[0]. That is true, but the function will not return 1 (true, a match was found in elist) when there is only one exception stored. It will skip over the while loop, set *ip to 0, and return 0 (false, the exception was not found!). This can be illustrated: 1) Call the program, setting only one exception (in this case unit 21): [shane@shane-laptop ~/temp/testgfortran]$ GFORTRAN_CONVERT_UNIT='native;big_endian:21' gnu_wrap gdb ./test_read 2) Set a break point at where the library enquires as to the endianness of the file to be opened: Breakpoint 1, _gfortrani_get_unformatted_convert (unit=21) at ../../../libgfortran/runtime/environ.c:848 3) We will step into search_unit (with unit = 21). Everything is great. however, since n_elist = 1, high = low = 0, and the while loop is skipped over: (gdb) step 471 while (high - low > 1) (gdb) step 485 if (unit > elist[high].unit) 4) And 0 is returned (unit exception not found!) (gdb) step 490 return 0; 5) The library is told to open unit 21 (which is in the exception list at 0) as default endianness: _gfortrani_get_unformatted_convert (unit=21) at ../../../libgfortran/runtime/environ.c:856 856 return def;
[Bug libfortran/54736] GFORTRAN_CONVERT_UNIT causes malloc error on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54736 --- Comment #4 from tkoenig at netcologne dot de 2012-09-30 20:24:03 UTC --- Am 30.09.2012 21:12, schrieb shart6 at utk dot edu: > If n_elist = 1, then high = low = 0, and the funtion will always return 0, > even > if the unit passed in to search for is in the exception list. If there are n_elist exceptions, then they can be found in elist[0], ..., elist[n_elist-1]. If there is one exception, then it can be found at elist[0].
[Bug rtl-optimization/38449] delay branch scheduling follows REG_CROSSING_JUMP jumps indiscriminately
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38449 --- Comment #4 from Jorn Wolfgang Rennecke 2012-09-30 19:25:53 UTC --- Author: amylaar Date: Sun Sep 30 19:25:49 2012 New Revision: 191878 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191878 Log: PR rtl-optimization/38449: * hooks.c (hook_bool_const_rtx_const_rtx_true): New function. * hooks.h (hook_bool_const_rtx_const_rtx_true): Declare. * target.def: Merge in definitions and documentation for TARGET_CAN_FOLLOW_JUMP. * doc/tm.texi.in: Add documentation locations for the above. * doc/tm.texi: Regenerate. * reorg.c (follow_jumps): New parameters jump and crossing. Changed all callers. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/hooks.c trunk/gcc/hooks.h trunk/gcc/reorg.c trunk/gcc/target.def
[Bug libfortran/54736] GFORTRAN_CONVERT_UNIT causes malloc error on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54736 --- Comment #3 from Shane Hart 2012-09-30 19:12:48 UTC --- The patch does get rid of memory corruption. However, there seem to be some problems with search_unit returning true if an exception is found when there is only one exception. If n_elist = 1, then high = low = 0, and the funtion will always return 0, even if the unit passed in to search for is in the exception list.
[Bug target/54762] New: [SH] Utilize zero-displacement branches for conditional far branches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54762 Bug #: 54762 Summary: [SH] Utilize zero-displacement branches for conditional far branches Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: olege...@gcc.gnu.org Target: sh*-*-* When the displacement of a conditional branch is too small the branch is 'widened', which results in code like this (a random snippet from CSiBE): mov.l r8,@-r15 sts.l pr,@-r15 mov.l @(32,r4),r8 tst r8,r8 bt .L293 mov.l @r8,r1 cmp/eq r4,r1 bt .L295 <<< .L293: bra .L297 <<< mov #-2,r6 <<< .L295: mov.l @(4,r8),r2 < lots of code > .L297: In such cases zero-displacement branches could be utilized to branch around the far branch. For example: mov.l r8,@-r15 sts.l pr,@-r15 mov.l @(32,r4),r8 tst r8,r8 bf 0f bra .L297 0: mov #-2,r6 mov.l @r8,r1 cmp/eq r4,r1 bt 0f bra .L297 0: mov #-2,r6 mov.l @(4,r8),r2 < lots of code > .L297: Maybe this could be achieved by adding variations to the existing "branch_true" and "branch_false" patterns like: (define_insn "branch_true_far" [(set (pc) (if_then_else (ne (match_operand 1 "t_reg_operand" "") (const_int 0)) (label_ref (match_operand 0 "" "")) (pc)))] "TARGET_SH1" { return "bf 0f" "\n" "bra%l0" "\n" "0: %#"; } [(set_attr "type" "cbranch") (set_attr "needs_delay_slot" "yes") (set_attr "length" "4")]) ;; not sure whether length should be 4 or 6 ;; in this case...
[Bug middle-end/54759] [4.8 regression] segfault for gcc.dg/vect/pr49093.c on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54759 Dehao Chen changed: What|Removed |Added CC||dehao at google dot com --- Comment #1 from Dehao Chen 2012-09-30 19:05:05 UTC --- Thanks for reporting the bug. I prepared a patch to fix this: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01997.html Could you help verify if it is fixed by this? Thanks, Dehao
[Bug target/54089] [SH] Refactor shift patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #21 from Oleg Endo 2012-09-30 18:45:56 UTC --- I've noticed that there seems to be a problem with register allocation related to shift insns. For example in the CSiBE set, I've seen sequences such as mov.w .L342,r2 mov #0,r7 .align 2 .L340: mov r7,r1 add r2,r1 sharr1 mov r1,r3 <<< shll2 r3 <<< mov r3,r0 <<< mov.l @(r0,r5),r3 cmp/gt r4,r3 bf 0f quite often. Not sure why this happens. Maybe because 'gen_shifty_op' (which emits the shift sequence insns) is called after reload and not during the first split pass after combine...
[Bug target/54686] std::abs (long long) resorts to std::abs (double) if llabs is absent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|glisse at gcc dot gnu.org | AssignedTo|unassigned at gcc dot |glisse at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 --- Comment #30 from Paolo Carlini 2012-09-30 18:18:15 UTC --- Oops, I thought Marc was already in charge.
[Bug go/54761] FAIL log
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54761 --- Comment #2 from Uros Bizjak 2012-09-30 18:18:10 UTC --- Created attachment 28307 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28307 Output of readelf --debug
[Bug go/54761] FAIL log
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54761 --- Comment #1 from Uros Bizjak 2012-09-30 18:16:20 UTC --- Created attachment 28306 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28306 Gzipped test executable Gzipped alpha test executable, can be used with readelf.
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #16 from dave.anglin at bell dot net 2012-09-30 18:04:26 UTC --- I will commit the attached change if there are no objections. -- John David Anglindave.ang...@bell.net
[Bug fortran/54618] [OOP] wrong-code with CLASS(...), INTENT(OUT) -- and OPTIONAL or ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618 Tobias Burnus changed: What|Removed |Added Attachment #28269|0 |1 is obsolete|| Attachment #28278|0 |1 is obsolete|| --- Comment #13 from Tobias Burnus 2012-09-30 18:02:33 UTC --- Created attachment 28304 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28304 Updated OPTIONAL patch Current version of my OPTIONAL patch, just to make sure that I don't accidentally delete it locally. It fixes a bunch of issues; however, as the FIXMEs show, there are still wrong-code (segfault at run time) issues related to ELEMENTAL, scalar coarrays and possibly another issue. TODO: - Fix the OPTIONAL issues mentioned above - Support packing of assumed-rank arrays (see just attached test case; but otherwise an unrelated issue) - Fix INTENT(OUT) handling for allocatable polymorphic arrays (cf. comment 0) - Analyse the old issue related to class_array_7.f03 (comment 11, comment 12)
[Bug target/54083] FAIL: gcc.dg/torture/pr53922.c on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54083 --- Comment #10 from John David Anglin 2012-09-30 17:54:57 UTC --- Test is fixed on 32-bit hpux. Sorry, for messing up proposed patches.
[Bug go/54761] New: FAIL log
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54761 Bug #: 54761 Summary: FAIL log Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: ubiz...@gmail.com Host: alpha-unknown-linux-gnu Target: alpha-unknown-linux-gnu Build: alpha-unknown-linux-gnu log libgo test regressed again, probaby when libgo switched to libbacktrace. As instructed in PR52583, I am opening a new PR for this. make GOTESTFLAGS=--keep log/check --- FAIL: log.TestAll (0.01 seconds) ???:1: log output should match "^.*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "???:0: hello 23 world" ???:1: log output should match "^.*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "???:0: hello 23 world" ???:1: log output should match "^[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "???:0: hello 23 world" ???:1: log output should match "^[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "???:0: hello 23 world" ???:1: log output should match "^[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "???:0: hello 23 world" ???:1: log output should match "^[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "???:0: hello 23 world" ???:1: log output should match "^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9] [0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9] .*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "XXX2012/09/30 19:38:55.640536 ???:0: hello 23 world" ???:1: log output should match "^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9] [0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9] .*/[A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "XXX2012/09/30 19:38:55.641513 ???:0: hello 23 world" ???:1: log output should match "^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9] [0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9] [A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "XXX2012/09/30 19:38:55.642490 ???:0: hello 23 world" ???:1: log output should match "^XXX[0-9][0-9][0-9][0-9]/[0-9][0-9]/[0-9][0-9] [0-9][0-9]:[0-9][0-9]:[0-9][0-9]\\.[0-9][0-9][0-9][0-9][0-9][0-9] [A-Za-z0-9_\\-]+\\.go:(54|56): hello 23 world$" is "XXX2012/09/30 19:38:55.643466 ???:0: hello 23 world" FAIL ~/gcc-build/gcc/xgcc -v Using built-in specs. COLLECT_GCC=/home/uros/gcc-build/gcc/xgcc Target: alphaev68-unknown-linux-gnu Configured with: ../gcc-svn/trunk/configure --enable-languages=all,obj-c++,go Thread model: posix gcc version 4.8.0 20120930 (experimental) [trunk revision 191866] (GCC)
[Bug target/54686] std::abs (long long) resorts to std::abs (double) if llabs is absent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686 Oleg Endo changed: What|Removed |Added Attachment #28257|0 |1 is obsolete|| --- Comment #29 from Oleg Endo 2012-09-30 17:48:25 UTC --- Created attachment 28303 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28303 always define abs(long long) (v2.1) This an updated patch against rev 191865, with a typo fix (missing '\'). With this patch the std::abs problem goes away on my xgcc setup. So far I've tested it only with 'make all'.
[Bug target/54083] FAIL: gcc.dg/torture/pr53922.c on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54083 --- Comment #9 from John David Anglin 2012-09-30 17:44:09 UTC --- Author: danglin Date: Sun Sep 30 17:44:04 2012 New Revision: 191874 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191874 Log: PR target/54083 * gcc.dg/torture/pr53922.c: Skip on 32-bit hppa-*-hpux*. Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr53922.c
[Bug target/54083] FAIL: gcc.dg/torture/pr53922.c on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54083 --- Comment #8 from John David Anglin 2012-09-30 17:41:55 UTC --- Author: danglin Date: Sun Sep 30 17:41:49 2012 New Revision: 191873 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191873 Log: PR target/54083 * gcc.dg/torture/pr53922.c: Skip on 32-bit hppa-*-hpux*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/pr53922.c
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #15 from Paolo Carlini 2012-09-30 17:38:42 UTC --- I was joking, but I see many failures, not only for long double. Anyway, let's make sure we have a fall back, for now.
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #14 from dave.anglin at bell dot net 2012-09-30 17:15:24 UTC --- On 30-Sep-12, at 12:16 PM, paolo.carlini at oracle dot com wrote: > Hopeless ;) Actually, the situation might not be completely hopeless as the libquadmath support works... I had planned to implement the long double aliases but haven't had time to get around to it. -- John David Anglindave.ang...@bell.net
[Bug fortran/54618] [OOP] wrong-code with CLASS(...), INTENT(OUT) -- and OPTIONAL or ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618 --- Comment #12 from Tobias Burnus 2012-09-30 17:01:26 UTC --- (In reply to comment #11) > With the patch in comment #10, gfortran (otherwise clean r191847) miscompiles > gfortran.dg/class_array_7.f03. Seems to be fixed by my much extended local version (which still has some issues related to polymorphic coarrays). The following issue I see, however, also with GCC 4.7. I think it should be investigated and seems to be unrelated to my patch: > ==96855== Invalid read of size 4 > ==96855==at 0x11782: __realloc_MOD_assign (class_array_7_db.f90:25) > ==96855==by 0x11685: __realloc_MOD_reallocate > (class_array_7_db.f90:34)
[Bug target/54760] [SH] Add __builtin_thread_pointer, __builtin_set_thread_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54760 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-30 Ever Confirmed|0 |1
[Bug target/54760] New: [SH] Add __builtin_thread_pointer, __builtin_set_thread_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54760 Bug #: 54760 Summary: [SH] Add __builtin_thread_pointer, __builtin_set_thread_pointer Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: olege...@gcc.gnu.org ReportedBy: olege...@gcc.gnu.org Target: sh*-*-* SH normally uses GBR to store the address of the thread control block (TCB). Other targets have __builtin_thread_pointer and __builtin_set_thread_pointer to modify such registers. It has been proposed to make these machine independent builtins: http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00428.html but so far this has not made it into mainline. In any case the builtin functions should be added for SH to get/set the GBR. Moreover, code that accesses variables in the TCB like struct tcb { int a, b, c, d; }; int test (void) { return ((tcb*)__builtin_thread_pointer ())->c; } ideally would result in: rts mov.l @(8,gbr),r0
[Bug fortran/54667] [OOP] gimplification failure with c_f_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54667 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from janus at gcc dot gnu.org 2012-09-30 16:42:23 UTC --- Fixed with r191870. Closing. Thanks for the report, Andrew!
[Bug libfortran/54736] GFORTRAN_CONVERT_UNIT causes malloc error on several platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54736 Thomas Koenig changed: What|Removed |Added Keywords||wrong-code URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-09/msg01962.htm ||l --- Comment #2 from Thomas Koenig 2012-09-30 16:38:10 UTC --- Patch posted.
[Bug fortran/54667] [OOP] gimplification failure with c_f_pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54667 --- Comment #12 from janus at gcc dot gnu.org 2012-09-30 16:36:09 UTC --- Author: janus Date: Sun Sep 30 16:36:02 2012 New Revision: 191870 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191870 Log: 2012-09-30 Janus Weil PR fortran/54667 * intrinsic.texi (C_F_POINTER): Fix description. * resolve.c (gfc_iso_c_sub_interface): Add a check for FPTR argument of C_F_POINTER. Modify two error messages. Cleanup. 2012-09-30 Janus Weil PR fortran/54667 * gfortran.dg/c_funloc_tests_6.f90: Modified error message. * gfortran.dg/c_f_pointer_shape_test.f90: Ditto. * gfortran.dg/c_f_pointer_tests_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/c_f_pointer_tests_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/c_f_pointer_shape_test.f90 trunk/gcc/testsuite/gfortran.dg/c_funloc_tests_6.f90
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #13 from Paolo Carlini 2012-09-30 16:16:25 UTC --- Hopeless ;)
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #12 from dave.anglin at bell dot net 2012-09-30 16:06:52 UTC --- On 30-Sep-12, at 10:19 AM, glisse at gcc dot gnu.org wrote: > Dominique, it would be more useful if you could show your libstdc++ > config.log, > and in particular the error message you got for the test "for ISO > C99 support > to TR1 in ", to know what functions are missing on darwin > (or hppa or > others), assuming there isn't already a PR somewhere about it. FWIW, the HP-UX 11.11 list is: configure:18907: checking for ISO C99 support to TR1 in configure:19031: /test/gnu/gcc/objdir/./gcc/xgcc -shared-libgcc -B/ test/gnu/gcc /objdir/./gcc -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/ libstdc++ -v3/src -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/ src/.libs -B/o pt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.8/ hppa2.0w-hp -hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/ include -isy stem /opt/gnu/gcc/gcc-4.8/hppa2.0w-hp-hpux11.11/sys-include-c -g - O2 -std=c+ +98 conftest.cpp >&5 conftest.cpp: In function 'int main()': conftest.cpp:67:16: error: 'acoshf' was not declared in this scope acoshf(0.0f); ^ conftest.cpp:68:16: error: 'acoshl' was not declared in this scope acoshl(0.0l); ^ conftest.cpp:70:16: error: 'asinhf' was not declared in this scope asinhf(0.0f); ^ conftest.cpp:71:16: error: 'asinhl' was not declared in this scope asinhl(0.0l); ^ conftest.cpp:73:16: error: 'atanhf' was not declared in this scope atanhf(0.0f); ^ conftest.cpp:74:16: error: 'atanhl' was not declared in this scope atanhl(0.0l); ^ conftest.cpp:77:15: error: 'cbrtl' was not declared in this scope cbrtl(0.0l); ^ conftest.cpp:80:25: error: 'copysignl' was not declared in this scope copysignl(0.0l, 0.0l); ^ conftest.cpp:82:14: error: 'erff' was not declared in this scope erff(0.0f); ^ conftest.cpp:83:14: error: 'erfl' was not declared in this scope erfl(0.0l); ^ conftest.cpp:85:15: error: 'erfcf' was not declared in this scope erfcf(0.0f); ^ conftest.cpp:86:15: error: 'erfcl' was not declared in this scope erfcl(0.0l); ^ conftest.cpp:88:15: error: 'exp2f' was not declared in this scope exp2f(0.0f); ^ conftest.cpp:89:15: error: 'exp2l' was not declared in this scope exp2l(0.0l); ^ conftest.cpp:91:16: error: 'expm1f' was not declared in this scope expm1f(0.0f); ^ conftest.cpp:92:16: error: 'expm1l' was not declared in this scope expm1l(0.0l); ^ conftest.cpp:94:21: error: 'fdimf' was not declared in this scope fdimf(0.0f, 0.0f); ^ conftest.cpp:95:21: error: 'fdiml' was not declared in this scope fdiml(0.0l, 0.0l); ^ conftest.cpp:96:22: error: 'fma' was not declared in this scope fma(0.0, 0.0, 0.0); ^ conftest.cpp:97:26: error: 'fmaf' was not declared in this scope fmaf(0.0f, 0.0f, 0.0f); ^ conftest.cpp:98:26: error: 'fmal' was not declared in this scope fmal(0.0l, 0.0l, 0.0l); ^ conftest.cpp:100:21: error: 'fmaxf' was not declared in this scope fmaxf(0.0f, 0.0f); ^ conftest.cpp:101:21: error: 'fmaxl' was not declared in this scope fmaxl(0.0l, 0.0l); ^ conftest.cpp:103:21: error: 'fminf' was not declared in this scope fminf(0.0f, 0.0f); ^ conftest.cpp:104:21: error: 'fminl' was not declared in this scope fminl(0.0l, 0.0l); ^ conftest.cpp:106:22: error: 'hypotf' was not declared in this scope hypotf(0.0f, 0.0f); ^ conftest.cpp:107:22: error: 'hypotl' was not declared in this scope hypotl(0.0l, 0.0l); ^ conftest.cpp:109:16: error: 'ilogbf' was not declared in this scope ilogbf(0.0f); ^ conftest.cpp:110:16: error: 'ilogbl' was not declared in this scope ilogbl(0.0l); ^ conftest.cpp:112:17: error: 'lgammaf' was not declared in this scope lgammaf(0.0f); ^ conftest.cpp:113:17: error: 'lgammal' was not declared in this scope lgammal(0.0l); ^ conftest.cpp:115:17: error: 'llrintf' was not declared in this scope llrintf(0.0f); ^ conftest.cpp:116:17: error: 'llrintl' was not declared in this scope llrintl(0.0l); ^ conftest.cpp:118:18: error: 'llroundf' was not declared in this scope ll
[Bug testsuite/54148] FAIL: gcc.dg/plugin/selfassign.c compilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54148 --- Comment #4 from John David Anglin 2012-09-30 15:52:35 UTC --- Tests don't fail with full bootstrap. It appears TESTING_IN_BUILD_TREE should not be output to site.exp when full build tree isn't available.
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #11 from Paolo Carlini 2012-09-30 15:48:36 UTC --- Just confirmed that Snow Leopard is still Ok. As far as I'm concerned, the current status is good enough.
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #10 from Dominique d'Humieres 2012-09-30 15:37:29 UTC --- > Note that the last time I checked, on Leopard, darwin actually enabled > _GLIBCXX_USE_C99_MATH_TR1. Well I may have been too quick to say *-*-darwin*, I am sure of ppc-darwin9 and x64_86-darwin10. Apparently there is no failure for the libstdc++ tests and x64_86-darwin12 (see http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg02713.html).
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #9 from Dominique d'Humieres 2012-09-30 15:33:18 UTC --- (In reply to comment #7) > > include/c++/4.8.0/cmath for darwin > > Dominique, it would be more useful if you could show your libstdc++ > config.log, > and in particular the error message you got for the test "for ISO C99 support > to TR1 in ", to know what functions are missing on darwin (or hppa or > others), assuming there isn't already a PR somewhere about it. I see ... configure:18907: checking for ISO C99 support to TR1 in configure:19031: /opt/gcc/build_w/./gcc/xgcc -shared-libgcc -B/opt/gcc/build_w/./gcc -nostdinc++ -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc ++-v3/src -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/bin/ -B/opt/gcc/gcc4.8w/x86 _64-apple-darwin10.8.0/lib/ -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/include -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/sys-includ e-c -g -O2 -std=c++98 conftest.cpp >&5 conftest.cpp: In function 'int main()': conftest.cpp:129:15: error: 'llrint' was not declared in this scope llrint(0.0); ^ conftest.cpp:130:17: error: 'llrintf' was not declared in this scope llrintf(0.0f); ^ conftest.cpp:131:17: error: 'llrintl' was not declared in this scope llrintl(0.0l); ^ conftest.cpp:132:16: error: 'llround' was not declared in this scope llround(0.0); ^ conftest.cpp:133:18: error: 'llroundf' was not declared in this scope llroundf(0.0f); ^ conftest.cpp:134:18: error: 'llroundl' was not declared in this scope llroundl(0.0l); ^ configure:19031: $? = 1 configure: failed program was: ... configure:19040: result: no configure:19052: checking for ISO C99 support to TR1 in configure:19072: /opt/gcc/build_w/./gcc/xgcc -shared-libgcc -B/opt/gcc/build_w/./gcc -nostdinc++ -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/bin/ -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/lib/ -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/include -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/sys-include-c -g -O2 -std=c++98 conftest.cpp >&5 configure:19072: $? = 0 configure:19079: result: yes ... configure:19127: checking stdbool.h usability ... configure:21386: result: no configure:21408: checking for hypot declaration configure:21433: /opt/gcc/build_w/./gcc/xgcc -shared-libgcc -B/opt/gcc/build_w/./gcc -nostdinc++ -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src -L/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/bin/ -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/lib/ -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/include -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/sys-include-c -fno-builtin -D_GNU_SOURCE conftest.cpp >&5 configure:21433: $? = 0 configure:21449: result: yes configure:21455: checking for hypot configure:21455: /opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/ -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/bin/ -B/opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/lib/ -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/include -isystem /opt/gcc/gcc4.8w/x86_64-apple-darwin10.8.0/sys-include-o conftest -g -O2 conftest.c -lm >&5 conftest.c:134:6: warning: conflicting types for built-in function 'hypot' [enabled by default] char hypot (); ^ configure:21455: $? = 0 configure:21455: result: yes configure:21529: checking for float trig functions ... + the same for hypotf and hypotl. Is it enough or should I attach the full log?
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #8 from Paolo Carlini 2012-09-30 15:32:09 UTC --- Note that the last time I checked, on Leopard, darwin actually enabled _GLIBCXX_USE_C99_MATH_TR1.
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #7 from Marc Glisse 2012-09-30 14:19:20 UTC --- (In reply to comment #5) > include/c++/4.8.0/cmath for darwin Dominique, it would be more useful if you could show your libstdc++ config.log, and in particular the error message you got for the test "for ISO C99 support to TR1 in ", to know what functions are missing on darwin (or hppa or others), assuming there isn't already a PR somewhere about it.
[Bug other/53313] Add warning levels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #4 from Manuel López-Ibáñez 2012-09-30 13:16:16 UTC --- I don't have a strong opinion on whether numeric levels or Weverything are a good idea or not. However, the issues you mention with -Wextra and -Weffc++ (PR16166) are clear-cut: if you propose a patch fixing them, they will be accepted. There is also the problem that the infrastructure for defining flags that enable other flags is quite rudimentary PR53063. If done properly, the documentation about which warnings enable other warnings could be automatically generated. If you really really want to implement a -Weverything, I would start by submitting a patch that makes -Weverything = -Wall + -Wextra + -Wconversion + a bunch of generally useful warnings not included in -Wall or -Wextra and see what happens. Probably you will need to negotiate the specific list of warnings (or the name of -Weverything, e.g., -Wparanoid) with the maintainers, but I think that it should be possible to find a set of "very noisy but sometimes useful" warnings. But the key point is that very likely nobody is going to implement any of this for you. Clang introduced the concept of categories for diagnostics, which seems much more interesting to me than numeric levels. But I don't really know what is the consensus about this in GCC.
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #6 from Paolo Carlini 2012-09-30 13:14:25 UTC --- Simply, atan2 is C89, hypot is C99. Confirmed that we don't have to do anything special besides making sure that C99 functions like hypot aren't used when _GLIBCXX_USE_C99_MATH_TR1 is not defined. In particular, we definitely don't want to fiddle with the global namespace, a sure recipe for maintainance nightmare.
[Bug fortran/54618] [OOP] wrong-code with CLASS(...), INTENT(OUT) -- and OPTIONAL or ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-30 Ever Confirmed|0 |1 --- Comment #11 from Dominique d'Humieres 2012-09-30 12:51:11 UTC --- With the patch in comment #10, gfortran (otherwise clean r191847) miscompiles gfortran.dg/class_array_7.f03. If I replace the "if ... abort()" with prints, I get a is extended_type tmp is base_type a is extended_type a.out(83666) malloc: *** error for object 0x100200f80: pointer being freed was not allocated or [macbook] f90/bug% valgrind a.out ==96855== Memcheck, a memory error detector ==96855== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==96855== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==96855== Command: a.out ==96855== a is extended_type tmp is base_type ==96855== Invalid read of size 4 ==96855==at 0x11782: __realloc_MOD_assign (class_array_7_db.f90:25) ==96855==by 0x11685: __realloc_MOD_reallocate (class_array_7_db.f90:34) ==96855==by 0x11A61: MAIN__ (class_array_7_db.f90:57) ==96855==by 0x11BD5: main (class_array_7_db.f90:50) ==96855== Address 0x100442408 is 0 bytes after a block of size 40 alloc'd ==96855==at 0x100013679: malloc (vg_replace_malloc.c:266) ==96855==by 0x11830: MAIN__ (class_array_7_db.f90:54) ==96855==by 0x11BD5: main (class_array_7_db.f90:50) ==96855== a is extended_type ==96855== Invalid free() / delete / delete[] / realloc() ==96855==at 0x10001352D: free (vg_replace_malloc.c:430) ==96855==by 0x11B9D: MAIN__ (class_array_7_db.f90:60) ==96855==by 0x11BD5: main (class_array_7_db.f90:50) ==96855== Address 0x1004423e0 is 0 bytes inside a block of size 40 free'd ==96855==at 0x10001352D: free (vg_replace_malloc.c:430) ==96855==by 0x116BB: __realloc_MOD_reallocate (class_array_7_db.f90:35) ==96855==by 0x11A61: MAIN__ (class_array_7_db.f90:57) ==96855==by 0x11BD5: main (class_array_7_db.f90:50) ==96855== ==96855== ==96855== HEAP SUMMARY: ==96855== in use at exit: 168 bytes in 2 blocks ==96855== total heap usage: 25 allocs, 24 frees, 7,321 bytes allocated ==96855== ==96855== LEAK SUMMARY: ==96855==definitely lost: 80 bytes in 1 blocks ==96855==indirectly lost: 0 bytes in 0 blocks ==96855== possibly lost: 0 bytes in 0 blocks ==96855==still reachable: 0 bytes in 0 blocks ==96855== suppressed: 88 bytes in 1 blocks ==96855== Rerun with --leak-check=full to see details of leaked memory ==96855== ==96855== For counts of detected and suppressed errors, rerun with: -v ==96855== ERROR SUMMARY: 6 errors from 2 contexts (suppressed: 0 from 0) Otherwise the patch works as advertised.
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 --- Comment #5 from Dominique d'Humieres 2012-09-30 12:36:38 UTC --- Created attachment 28302 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28302 include/c++/4.8.0/cmath for darwin
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 Dominique d'Humieres changed: What|Removed |Added Target|hppa2.0w-hp-hpux11.11 |hppa2.0w-hp-hpux11.11 ||*-*-darwin* Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-30 Host|hppa2.0w-hp-hpux11.11 |hppa2.0w-hp-hpux11.11 ||*-*-darwin* Ever Confirmed|0 |1 Build|hppa2.0w-hp-hpux11.11 |hppa2.0w-hp-hpux11.11 ||*-*-darwin* --- Comment #4 from Dominique d'Humieres 2012-09-30 12:35:12 UTC --- I also see it on *-*-darwin*. I have silenced the failures by replacing std:hypot with hypot. I have tested the example from http://en.cppreference.com/w/cpp/numeric/math/hypot , i.e., #include #include #include std::pair cartesian_to_polar(double x, double y) { return {std::hypot(x, y), std::atan2(y,x)}; } int main() { std::pair polar = cartesian_to_polar(1, 1); std::cout << "(1,1) cartesian is (" << polar.first << "," << polar.second<< ") polar\n"; } which fails to compile on darwin with [macbook] f90/bug% g++48 -std=c++11 polar.cpp polar.cpp: In function 'std::pair cartesian_to_polar(double, double)': polar.cpp:7:13: error: 'hypot' is not a member of 'std' return {std::hypot(x, y), std::atan2(y,x)}; ^ polar.cpp:7:13: note: suggested alternative: In file included from /usr/include/math.h:28:0, from /opt/gcc/gcc4.8w/include/c++/4.8.0/cmath:46, from polar.cpp:1: /usr/include/architecture/i386/math.h:340:15: note: 'hypot' extern double hypot ( double, double ); ^ polar.cpp:7:46: error: could not convert '{, atan2(y, x)}' from '' to 'std::pair' return {std::hypot(x, y), std::atan2(y,x)}; ^ while it compiles if I replace " return {std::hypot(x, y), std::atan2(y,x)};" with " return {hypot(x, y), std::atan2(y,x)}; ". Looking at include/c++/4.8.0/cmath, I don't understand why std::atan2(y,x) is found, but not std::hypot(x, y).
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #86 from Joost VandeVondele 2012-09-30 12:30:43 UTC --- (In reply to comment #84) LTO might work for many codes, as using allocatables in derived types was not standard Fortran90 (IIRC) and appears needed to trigger the bug. Anyway, since most people will use released versions of gcc, this checking error will be hidden behind --enable-checking=release. Only very few people will be able to locate and in particular reduce wrong code generation that only happens with LTO, so I wouldn't expect bug reports for actual wrong code generation very quickly. Meanwhile a shorter testcase for 4.8, using gfortran -flto -O0. TYPE t REAL, DIMENSION(:), ALLOCATABLE :: r END TYPE t TYPE t_p TYPE(t), POINTER :: d_t END TYPE t_p REAL, DIMENSION(:), POINTER:: d TYPE(t_p) :: x d=>x%d_t%r END
[Bug libstdc++/54577] deque::erase() still takes iterator instead of const_iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54577 --- Comment #2 from Jonathan Wakely 2012-09-30 11:40:11 UTC --- Author: redi Date: Sun Sep 30 11:40:06 2012 New Revision: 191866 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191866 Log: PR libstdc++/54577 * doc/xml/manual/status_cxx2011.xml: N2350 changes are missing from sequence containers. * doc/html/*: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/html/api.html trunk/libstdc++-v3/doc/html/faq.html trunk/libstdc++-v3/doc/html/index.html trunk/libstdc++-v3/doc/html/manual/abi.html trunk/libstdc++-v3/doc/html/manual/algorithms.html trunk/libstdc++-v3/doc/html/manual/api.html trunk/libstdc++-v3/doc/html/manual/appendix_contributing.html trunk/libstdc++-v3/doc/html/manual/appendix_free.html trunk/libstdc++-v3/doc/html/manual/appendix_gpl.html trunk/libstdc++-v3/doc/html/manual/appendix_porting.html trunk/libstdc++-v3/doc/html/manual/atomics.html trunk/libstdc++-v3/doc/html/manual/backwards.html trunk/libstdc++-v3/doc/html/manual/bk01pt02.html trunk/libstdc++-v3/doc/html/manual/bk01pt03ch17s03.html trunk/libstdc++-v3/doc/html/manual/bk01pt03ch18s03.html trunk/libstdc++-v3/doc/html/manual/bk01pt03ch19s02.html trunk/libstdc++-v3/doc/html/manual/bk01pt03ch19s07.html trunk/libstdc++-v3/doc/html/manual/bk01pt03ch21s02.html trunk/libstdc++-v3/doc/html/manual/bk01pt03pr01.html trunk/libstdc++-v3/doc/html/manual/bk01pt04.html trunk/libstdc++-v3/doc/html/manual/concurrency.html trunk/libstdc++-v3/doc/html/manual/configure.html trunk/libstdc++-v3/doc/html/manual/containers.html trunk/libstdc++-v3/doc/html/manual/diagnostics.html trunk/libstdc++-v3/doc/html/manual/documentation_hacking.html trunk/libstdc++-v3/doc/html/manual/extensions.html trunk/libstdc++-v3/doc/html/manual/facets.html trunk/libstdc++-v3/doc/html/manual/index.html trunk/libstdc++-v3/doc/html/manual/intro.html trunk/libstdc++-v3/doc/html/manual/io.html trunk/libstdc++-v3/doc/html/manual/iterators.html trunk/libstdc++-v3/doc/html/manual/localization.html trunk/libstdc++-v3/doc/html/manual/memory.html trunk/libstdc++-v3/doc/html/manual/numerics.html trunk/libstdc++-v3/doc/html/manual/parallel_mode.html trunk/libstdc++-v3/doc/html/manual/policy_data_structures.html trunk/libstdc++-v3/doc/html/manual/policy_data_structures_design.html trunk/libstdc++-v3/doc/html/manual/policy_data_structures_using.html trunk/libstdc++-v3/doc/html/manual/profile_mode.html trunk/libstdc++-v3/doc/html/manual/status.html trunk/libstdc++-v3/doc/html/manual/strings.html trunk/libstdc++-v3/doc/html/manual/support.html trunk/libstdc++-v3/doc/html/manual/test.html trunk/libstdc++-v3/doc/html/manual/using.html trunk/libstdc++-v3/doc/html/manual/using_exceptions.html trunk/libstdc++-v3/doc/html/manual/using_headers.html trunk/libstdc++-v3/doc/html/manual/utilities.html trunk/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025 Jonathan Wakely changed: What|Removed |Added Attachment #28188|0 |1 is obsolete|| --- Comment #10 from Jonathan Wakely 2012-09-30 10:58:18 UTC --- Comment on attachment 28188 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28188 Testcase for Bug "error: invalid initialization of non-const reference of type ‘std::istream&" (In reply to comment #9) > Created attachment 28188 [details] > Testcase for Bug "error: invalid initialization of non-const reference of type > ‘std::istream&" > > Mysterious compiler error in line 35 of the attached testcase (test1.cpp); > marked there as "BUG": > > test1.cpp:35:45: error: invalid initialization of non-const reference of type > ‘std::istream& {aka std::basic_istream&}’ from an rvalue of type ‘void*’ That's not mysterious, and is not related to this bug report. Your code can be reduced to: struct Base { operator void*() { return 0; } }; struct Derived1 : Base { }; struct Derived2 : Base { }; Derived1 d1; Derived2 d2; Base& b = true ? d1 : d2; The conditional expression cannot implicitly convert two objects of different types to a common base class, so instead the conversion operator is used to convert both types to void* To force the behaviour you expect use an explicit cast on one operand: istream& si = sfile.is_open() ? (std::istream&)sfile : sbuf;
[Bug middle-end/54759] New: [4.8 regression] segfault for gcc.dg/vect/pr49093.c on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54759 Bug #: 54759 Summary: [4.8 regression] segfault for gcc.dg/vect/pr49093.c on Solaris Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: ebotca...@gcc.gnu.org CC: de...@gcc.gnu.org Host: sparc-sun-solaris2.10 Target: sparc-sun-solaris2.10 Build: sparc-sun-solaris2.10 We have a segfault for gcc.dg/vect/pr49093.c on SPARC/Solaris: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0xff0ae9b0 in strlen () from /lib/libc.so.1 (gdb) bt #0 0xff0ae9b0 in strlen () from /lib/libc.so.1 #1 0xff1134d8 in _ndoprnt () from /lib/libc.so.1 #2 0xff1154a0 in fprintf () from /lib/libc.so.1 #3 0x00743778 in vectorize_loops () at /nile.build/botcazou/gcc-head/src/gcc/tree-vectorizer.c:198 #4 0x0067739c in tree_vectorize () at /nile.build/botcazou/gcc-head/src/gcc/tree-ssa-loop.c:215 (gdb) frame 3 #3 0x00743778 in vectorize_loops () at /nile.build/botcazou/gcc-head/src/gcc/tree-vectorizer.c:198 198 LOC_FILE (vect_location), LOC_LINE (vect_location)); (gdb) list 193 194 vect_location = find_loop_location (loop); 195 if (vect_location != UNKNOWN_LOC 196 && vect_verbosity_level > REPORT_NONE) 197 fprintf (vect_dump, "\nAnalyzing loop at %s:%d\n", 198 LOC_FILE (vect_location), LOC_LINE (vect_location)); 199 200 loop_vinfo = vect_analyze_loop (loop); 201 loop->aux = loop_vinfo; 202 (gdb) p vect_location $1 = 2147483648 (gdb) call expand_location(vect_location) $4 = {file = 0x0, line = 0, column = 0, data = 0xfb4a5ad0, sysp = false} This is reproducible with a bare cross-compiler on x86_64-suse-linux: gdb --args gcc/cc1 -quiet -O1 -ftree-vectorize -fdump-tree-vect-details -fno-tree-fre -mcpu=v9 pr49093.c (gdb) b tree-vectorizer.c:197 Breakpoint 1, vectorize_loops () at /home/eric/svn/gcc/gcc/tree-vectorizer.c:198 198 LOC_FILE (vect_location), LOC_LINE (vect_location)); (gdb) call expand_location(vect_location) $4 = {file = 0x0, line = 0, column = 0, data = 0x768dfaa0, sysp = false}
[Bug rtl-optimization/54739] [4.8 regression] FAIL: gcc.dg/lower-subreg-1.c scan-rtl-dump subreg1 "Splitting reg"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54739 Eric Botcazou changed: What|Removed |Added Target|m68k-*-*| CC||ebotcazou at gcc dot ||gnu.org --- Comment #2 from Eric Botcazou 2012-09-30 09:52:23 UTC --- And on the SPARC.
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #3 from Paolo Carlini 2012-09-30 09:44:27 UTC --- Hi, > There is an implementation of hypot, so I'm wondering if we can't do > better. You mean in the libc? It's possible because as you can see the autoconf test handles all the C99 mathematical functions together and if only one is missing the check fails. Now, really, I don't think we want to go fine grained to the level of the single function, but if for example we figure out that a number of targets has available the entire subset of functions required for and we could separate those. My point is that we should try to find patterns, like the long double functions are causing troubles and we can separate those. As I said, for those features - isn't just about math - I would rather not fragment everything down to single function, if possible. > Testing suggestion. Great, if it works, let's go with that for now. Then, longer term, if you have ideas about the above, please also feel free to send a message to the library mailing list.
[Bug libstdc++/54757] FAIL: ext/random/beta_distribution/cons/default.cc (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54757 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #3 from Paolo Carlini 2012-09-30 09:44:27 UTC --- Hi, > There is an implementation of hypot, so I'm wondering if we can't do > better. You mean in the libc? It's possible because as you can see the autoconf test handles all the C99 mathematical functions together and if only one is missing the check fails. Now, really, I don't think we want to go fine grained to the level of the single function, but if for example we figure out that a number of targets has available the entire subset of functions required for and we could separate those. My point is that we should try to find patterns, like the long double functions are causing troubles and we can separate those. As I said, for those features - isn't just about math - I would rather not fragment everything down to single function, if possible. > Testing suggestion. Great, if it works, let's go with that for now. Then, longer term, if you have ideas about the above, please also feel free to send a message to the library mailing list.
[Bug fortran/54758] New: accessing gcc builtins from fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54758 Bug #: 54758 Summary: accessing gcc builtins from fortran Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@mat.ethz.ch I would like to experiment with prefetching in Fortran code (beyond -fprefetch-loop-arrays). A convenient way to do this would be access the gcc_builtins. I tried this the following way: INTERFACE SUBROUTINE builtin_prefetch(a) BIND(C,name="__builtin_prefetch") USE ISO_C_BINDING, ONLY: C_FLOAT REAL(KIND=C_FLOAT), dimension(*) :: a END SUBROUTINE END INTERFACE real*4 :: data(100) DO i=1,100 CALL builtin_prefetch(data(i)) data(i)=0 ENDDO END but it didn't work... test.f90:(.text+0x36): undefined reference to `__builtin_prefetch' no surprise, I guess, but it would be cool if it did.
[Bug other/53313] Add warning levels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313 Jan Kratochvil changed: What|Removed |Added CC||jan.kratochvil at redhat ||dot com --- Comment #3 from Jan Kratochvil 2012-09-30 07:24:30 UTC --- For example PR 35173 would not be filed and also I would find -Wconversion without Google if there was -Weverything.