[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support
--- Comment #3 from burnus at gcc dot gnu dot org 2010-04-14 06:33 --- Some underflow module for Fortran: http://gcc.gnu.org/ml/fortran/2010-04/msg00144.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383
[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]
--- Comment #20 from burnus at gcc dot gnu dot org 2010-04-14 05:43 --- Subject: Bug 18918 Author: burnus Date: Wed Apr 14 05:43:30 2010 New Revision: 158292 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158292 Log: 2010-04-14 Tobias Burnus PR fortran/18918 * array.c (gfc_find_array_ref): Handle codimensions. (gfc_match_array_spec,gfc_match_array_ref): Use gfc_fatal_error. * check.c (is_coarray, dim_corank_check, gfc_check_lcobound, gfc_check_image_index, gfc_check_this_image, gfc_check_ucobound): New functions. * gfortran.h (gfc_isym_id): Add GFC_ISYM_IMAGE_INDEX, GFC_ISYM_LCOBOUND, GFC_ISYM_THIS_IMAGE, GFC_ISYM_UCOBOUND. * intrinsic.h (add_functions): Add this_image, image_index, lcobound and ucobound intrinsics. * intrinsic.c (gfc_check_lcobound,gfc_check_ucobound, gfc_check_image_index, gfc_check_this_image, gfc_simplify_image_index, gfc_simplify_lcobound, gfc_simplify_this_image, gfc_simplify_ucobound): New function prototypes. * intrinsic.texi (IMAGE_INDEX, LCOBOUND, THIS_IMAGE IMAGE_INDEX): Document new intrinsic functions. * match.c (gfc_match_critical, sync_statement): Make * -fcoarray=none error fatal. * simplify.c (simplify_bound_dim): Handle coarrays. (simplify_bound): Update simplify_bound_dim call. (gfc_simplify_num_images): Add -fcoarray=none check. (simplify_cobound, gfc_simplify_lcobound, gfc_simplify_ucobound, gfc_simplify_ucobound, gfc_simplify_ucobound): New functions. 2010-04-14 Tobias Burnus PR fortran/18918 * gfortran.dg/coarray_9.f90: Update dg-errors. * gfortran.dg/coarray_10.f90: New test. * gfortran.dg/coarray_11.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/coarray_10.f90 trunk/gcc/testsuite/gfortran.dg/coarray_11.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/check.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/match.c trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/coarray_9.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918
[Bug fortran/43747] [4.6 Regression] ICE in find_array_section, at fortran/expr.c:1551
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-04-14 05:27 --- Subject: Bug 43747 Author: jvdelisle Date: Wed Apr 14 05:27:29 2010 New Revision: 158291 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158291 Log: 2010-04-14 Jerry DeLisle PR fortran/43747 gfortran.dg/initialization_24.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/initialization_24.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43747
[Bug fortran/43747] [4.6 Regression] ICE in find_array_section, at fortran/expr.c:1551
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-04-14 05:17 --- Subject: Bug 43747 Author: jvdelisle Date: Wed Apr 14 05:16:59 2010 New Revision: 158290 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158290 Log: 2010-04-14 Jerry DeLisle PR fortran/43747 * constructor.c: Fix typo in comment. * expr.c (find_array_section): Add check for max array limit. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/constructor.c trunk/gcc/fortran/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43747
[Bug fortran/43747] [4.6 Regression] ICE in find_array_section, at fortran/expr.c:1551
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-04-14 05:08 --- Easier then I thought. Patch submitted for approval. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43747
[Bug target/43742] [4.6 Regression] web.c/union_match_dups segfaults for a null *ref on sh-elf
--- Comment #5 from kkojima at gcc dot gnu dot org 2010-04-14 04:52 --- It looks that simply removing the problematic constraint from doloop_end_split restores build with no performance regressions. * config/sh/sh.md (doloop_end_split): Remove "+r" constraint in an input-only operand. --- ORIG/trunk/gcc/config/sh/sh.md 2010-04-12 09:52:36.0 +0900 +++ trunk/gcc/config/sh/sh.md 2010-04-14 10:18:47.0 +0900 @@ -7050,7 +7050,7 @@ label: (define_insn_and_split "doloop_end_split" [(set (pc) - (if_then_else (ne:SI (match_operand:SI 0 "arith_reg_dest" "+r") + (if_then_else (ne:SI (match_operand:SI 0 "arith_reg_dest" "") (const_int 1)) (label_ref (match_operand 1 "" "")) (pc))) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43742
[Bug c++/9335] repeated diagnostic when maximum template depth is exceeded
--- Comment #14 from jason at gcc dot gnu dot org 2010-04-14 01:41 --- That sounds like another case where trying to recover from an error by changing a problematic type to 'int' doesn't actually improve matters. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9335
[Bug fortran/43747] [4.6 Regression] ICE in find_array_section, at fortran/expr.c:1551
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-04-14 01:32 --- OK, I see it now. This is a little different from our previous encounters with overly big constructors. In fact, the code we had in place is still there, so we have whacked something. The test case does not fail at 65535 and does fail at 65536. I will study it a bit, but this may not be a quick one. (Unless I get lucky) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43747
[Bug target/43742] [4.6 Regression] web.c/union_match_dups segfaults for a null *ref on sh-elf
--- Comment #4 from kkojima at gcc dot gnu dot org 2010-04-14 00:55 --- (In reply to comment #3) > This seems to be due to a pattern that uses a "+" constraint in an input-only > operand. The attached patch seems to fix it for me; please confirm. [I'd like to add Christian to the cc list.] Although it solves the build failure for sh4-unknown-linux-gnu and a quick regtesting for c and c++ on that target shows no new failures, I see some performance regressions for programs using loops. Looks that it makes PR target/29953 reopen. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||chrbr at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43742
[Bug c++/9335] repeated diagnostic when maximum template depth is exceeded
--- Comment #13 from manu at gcc dot gnu dot org 2010-04-13 23:48 --- I have a patch that prints this: /home/manuel/src/pr9335.C:2:36: error: template instantiation depth exceeds maximum of 1024 (use -ftemplate-depth= to increase the maximum) instantiating struct X<-0x00018> /home/manuel/src/pr9335.C:2:36: recursively instantiated from const int X<1000>::value /home/manuel/src/pr9335.C:4:17: instantiated from here /home/manuel/src/pr9335.C:2:36: error: incomplete type X<-0x00018> used in nested name specifier /home/manuel/src/pr9335.C: In instantiation of const int X<-0x00016>::value: /home/manuel/src/pr9335.C:2:36: recursively instantiated from const int X<1000>::value /home/manuel/src/pr9335.C:4:17: instantiated from here /home/manuel/src/pr9335.C:2:36: error: X<-0x00016>::value cannot be initialized by a non-constant expression when being declared /home/manuel/src/pr9335.C: In instantiation of const int X<-0x00015>::value: /home/manuel/src/pr9335.C:2:36: recursively instantiated from const int X<1000>::value /home/manuel/src/pr9335.C:4:17: instantiated from here /home/manuel/src/pr9335.C:2:36: error: X<-0x00015>::value cannot be initialized by a non-constant expression when being declared /home/manuel/src/pr9335.C: In instantiation of const int X<-0x00014>::value: /home/manuel/src/pr9335.C:2:36: recursively instantiated from const int X<1000>::value /home/manuel/src/pr9335.C:4:17: instantiated from here then continues for 4000 lines It is perhaps an improvement but not a fix. @Jason, I see that in pt.c (instantiate_decl), after we get the first error, then init == error_mark_node. However, the parser continues building the declaration as if nothing. And we end up with something like: unit size align 32 symtab 0 alias set -1 canonical type 0x77490f18 precision 32 min max > readonly constant used public static tree_1 tree_2 tree_3 external nonlocal decl_3 decl_6 SI file /home/manuel/src/pr9335.C line 2 col 36 size unit size align 32 context initial template-info 0x77177600 chain > Couldn't we abort all this earlier? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9335
[Bug target/43493] exception ignores catch-clause when std::ostringstream helps in throwing
--- Comment #2 from gcc at cohi dot at 2010-04-13 21:26 --- (In reply to comment #1) > Most likely related to PR 43277. I want to say Darwin10's unwinder is broken > ... Can this be confirmed? The information in PR 43277, and the ones linked from there, seemed inconclusive... (I can file a bug-report with Apple, although it'll probably take them ages to actually do something about it.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43493
[Bug tree-optimization/42963] [4.5/4.6 Regression] Redundant switch labels not cleaned up anymore
--- Comment #5 from steven at gcc dot gnu dot org 2010-04-13 21:23 --- Matz, can you at least attach the patch to this PR, so that someone else can polish it if you're not going to do it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42963
[Bug fortran/43747] [4.6 Regression] ICE in find_array_section, at fortran/expr.c:1551
--- Comment #2 from burnus at gcc dot gnu dot org 2010-04-13 20:56 --- (In reply to comment #1) > I don't see the failure on linux-x86-64. I am building on Cygwin to see whta > shows up there. I seem to recall a patch that changed a fatal error to a > non-fatal somewhere. I will have a look tonight. I can reproduce the problem on linux-x86-64: f951: internal compiler error: in find_array_section, at fortran/expr.c:1551 -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-apple-darwin10 | GCC host triplet|x86_64-apple-darwin10 | GCC target triplet|x86_64-apple-darwin10 | Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2010-04-13 20:56:57 date|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43747
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #15 from dominiq at lps dot ens dot fr 2010-04-13 20:45 --- (In reply to comment #13) > Here we have index `i1' calculated from fp values and then casted to int. > Segmentation fault occurs in `y1 = y(i1)' with i1 equal to > 0x800c. > This is in function S00061 in doduc_red.f90, not in s33022.f90. This is because Re is a NaN because debm is a NaN. I tried to print deve and devs, but this make the code to work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug ada/43749] New: installed gnat cannot find installed libraries when exec-prefix != prefix
When building a compiler with --prefix=/some/dir and --exec-prefix=/some/dir/subdir, the installed gnat cannot find the installed libraries in /some/dir/subdir/lib/gcc/... I believe that sdefault.adb should be generated with S0 : constant String := \"$(exec_prefix)/\";" not S0 : constant String := \"$(prefix)/\";" in gcc/ada/Make-generated.in - when I modify as above, the installed gnat is able to find the installed adainclude and adalib correctly. (And the problem doesn't occur in the build tree, so the issue isn't apparent until the installed toolset is used). -- Summary: installed gnat cannot find installed libraries when exec-prefix != prefix Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dougsemler at gmail dot com GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43749
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #14 from mkuvyrkov at gcc dot gnu dot org 2010-04-13 20:01 --- (In reply to comment #10) > - D.1850_209 = -alt_90; > - D.2093_151 = -alb_86; > - D.1849_208 = D.1848_207 - alb_86; > + D.2093_151 = -alt_90; > + D.1849_208 = D.1848_207 - alt_90; >D.1851_210 = D.1849_208 + -1.0e+0; > - z1a_211 = D.1851_210 + D.1850_209; > + D.2094_497 = -alb_86; > + z1a_211 = D.1851_210 - alb_86; > > this doesn't look like an identity transform. You have to be careful with > non-single use vars and make sure they do not end up on a reassociation > chain. Though it does look fishy, this transformation is OK. In fact, the compiler oscillates a couple of times between using `-alb_86' and `-alt_90'. E.g., the "before" compiler does the following transformation during reassoc1: == - D.1849_208 = D.1848_207 - alb_86; + D.2045_228 = -alb_86; + D.1850_209 = -alt_90; + D.1849_208 = D.1848_207 + D.1850_209; == -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug bootstrap/43681] [4.6 Regression] bootstrap fails with "unused" var message for an apparently used var.
--- Comment #5 from ubizjak at gmail dot com 2010-04-13 19:46 ---
(In reply to comment #1)
> Created an attachment (id=20331)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20331&action=view) [edit]
> gcc46-pr43681.patch
>
> Untested patch.
How about:
Index: expr.c
===
--- expr.c (revision 158277)
+++ expr.c (working copy)
@@ -1251,7 +1251,7 @@
block_move_libcall_safe_for_call_parm (void)
{
#if defined (REG_PARM_STACK_SPACE)
- tree fn;
+ tree fn ATTRIBUTE_UNUSED;
#endif
/* If arguments are pushed on the stack, then they're safe. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43681
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #13 from mkuvyrkov at gcc dot gnu dot org 2010-04-13 19:32 --- The SIGSEGV is due to -funsafe-math-optimizations being used with code like: == Re = eps*debm*DIAhy/(vis*sec) reo = Re IF ( Re.LT.1000. ) THEN i1 = INT(Re/200.) + 1 ELSEIF ( Re.LT.4000. ) THEN i1 = INT(Re/500.) + 4 ELSEIF ( Re.LT.1. ) THEN i1 = INT(Re/2000.) + 10 ELSEIF ( Re.GE.3. ) THEN IF ( Re.GE.4. ) Re = 4.D+00 i1 = INT(Re/1.) + 16 ELSE i1 = INT(Re/5000.) + 13 ENDIF i2 = i1 + 1 y1 = y(i1) y2 = y(i2) == Here we have index `i1' calculated from fp values and then casted to int. Segmentation fault occurs in `y1 = y(i1)' with i1 equal to 0x800c. This is in function S00061 in doduc_red.f90, not in s33022.f90. Also, to trigger the SIGSEGV it is necessary to compile both doduc_red.f90 and s33022.f90 with "-O3 -funsafe-math-optimizations -ffinite-math-only". If either of the modules is compiled with -O2 the SIGSEGV does not occur. While I will not argue that my patch is 100% bug-free, this seems to be an invalid testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug fortran/43747] [4.6 Regression] ICE in find_array_section, at fortran/expr.c:1551
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2010-04-13 19:03 --- I don't see the failure on linux-x86-64. I am building on Cygwin to see whta shows up there. I seem to recall a patch that changed a fatal error to a non-fatal somewhere. I will have a look tonight. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43747
[Bug libgcj/40860] [4.4/4.5/4.6 regression] regressions in libjava testsuite on arm-linux
--- Comment #38 from aph at gcc dot gnu dot org 2010-04-13 17:25 --- I think I can fairly easily add an option to the linker to suppress table merging when linking Java libraries, and that will completely solve the problem, at least from my point of view. To that end, it would not be at all helpful to make _Unwind_GetRegionStart on ARM return NULL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug libgcj/40860] [4.4/4.5/4.6 regression] regressions in libjava testsuite on arm-linux
--- Comment #37 from aph at redhat dot com 2010-04-13 17:02 --- Subject: Re: [4.4/4.5/4.6 regression] regressions in libjava testsuite on arm-linux On 04/13/2010 05:52 PM, mikpe at it dot uu dot se wrote: >> Is it maybe the case that "Compact model 1" unwinder data isn't yet being >> merged? > > They have to be adjacent to be merged. Looks like there's something else > between f2 and f1 in your object code. (You are using binutils >= 2.20 right?) Yes. OK, that explains it: gcc trunk outputs the functions in a completely different order. Andrew. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #49 from howarth at nitro dot med dot uc dot edu 2010-04-13 16:59 --- (In reply to comment #48) > (d) temporarily patches darwin10.h to include the static lib first and > therefore work around this bug until the radar is done. >From what I was told (Comment 47), the radar bug may never be fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug other/43748] New: build machinery insufficient for installing target specific .def files as plugin headers
The current build machinery in FSF gcc doesn't appear to provide a mechanism to install target specific .def files when install-plugin installs the header files. In particular, after applying... http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00610.html ...and building gcc trunk or gcc-4_5-branch on x86_64-apple-darwin10 with --enable-plugin, the file gcc/config/darwin-sections.def isn't installed in with the plugin headers. The other definition files installed are explicitly listed in PLUGIN_HEADERS of gcc/Makefile.in. I have tried adding darwin-sections.def to tm_include in config.gcc for darwin but this doesn't allow the file to be installed. -- Summary: build machinery insufficient for installing target specific .def files as plugin headers Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: *-apple-darwin* GCC host triplet: *-apple-darwin* GCC target triplet: *-apple-darwin* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43748
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #48 from iains at gcc dot gnu dot org 2010-04-13 16:52 ---
give me a day or two guys...
and I'll post a composite patch that
(a) cleans up some of the nits in config{,/*}/darwin*.h
(b) gets rid of -lgcc [well, moves it to the only places it's still needed]
(c) sorts out dsymutils
(d) temporarily patches darwin10.h to include the static lib first and
therefore work around this bug until the radar is done.
.. I just need to sort out how to install the wrapper script..
(but I'm busy with a different problem today) :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug libgcj/40860] [4.4/4.5/4.6 regression] regressions in libjava testsuite on arm-linux
--- Comment #36 from mikpe at it dot uu dot se 2010-04-13 16:51 ---
(In reply to comment #35)
> I've been trying this on gcc trunk, and it doesn't have the problem.
> It seems that merging is not done.
>
> I get
>
> ...
> 0x8684 : @0x8808
> Compact model 1
> 0xb1 0x08 pop {r3}
> 0x84 0x00 pop {r14}
> 0xb0 finish
> 0xb0 finish
> ...
> 0x86b0 : @0x8820
> Compact model 1
> 0xb1 0x08 pop {r3}
> 0x84 0x00 pop {r14}
> 0xb0 finish
> 0xb0 finish
>
> Is it maybe the case that "Compact model 1" unwinder data isn't yet being
> merged?
They have to be adjacent to be merged. Looks like there's something else
between f2 and f1 in your object code. (You are using binutils >= 2.20 right?)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #47 from howarth at nitro dot med dot uc dot edu 2010-04-13 16:48 --- Not good news...according to another Apple programmer... -- Mike Stump filed the radar: ___divdc3 slightly wrong Since fixing it did not appear to positively impact our customers I recommended that either we reduce the priority appropriately +(e.g. Nice to have), or that we just close it. --- Perhaps Mike can update his radar with a more convincing appeal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug libgcj/40860] [4.4/4.5/4.6 regression] regressions in libjava testsuite on arm-linux
--- Comment #35 from aph at gcc dot gnu dot org 2010-04-13 16:36 ---
I've been trying this on gcc trunk, and it doesn't have the problem.
It seems that merging is not done.
I get
...
0x8684 : @0x8808
Compact model 1
0xb1 0x08 pop {r3}
0x84 0x00 pop {r14}
0xb0 finish
0xb0 finish
...
0x86b0 : @0x8820
Compact model 1
0xb1 0x08 pop {r3}
0x84 0x00 pop {r14}
0xb0 finish
0xb0 finish
Is it maybe the case that "Compact model 1" unwinder data isn't yet being
merged?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #46 from dominiq at lps dot ens dot fr 2010-04-13 16:29 --- > Did anyone ever file a radar bug report on the inaccurate complex math from > http://compiler-rt.llvm.org/? I did not see anything along this line in their bugzilla. However there is comment #25 > I've filed radr://7457013 for libSystem (aka libm on 10.6) to improve the > accuracy of ___divdc3. If that were fixed, then having -lm or not wouldn't > matter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #45 from howarth at nitro dot med dot uc dot edu 2010-04-13 16:06 --- Did anyone ever file a radar bug report on the inaccurate complex math from http://compiler-rt.llvm.org/? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #44 from howarth at nitro dot med dot uc dot edu 2010-04-13 16:01 --- >From a discussion with the clang programmers, I have this response... > > The FIXME comment in the clang sources caught my eye because, > > at first glance, it appears to be hinting that this usage > > of -lgcc might be eliminated in the future. > > Yes, all uses of -lgcc are going to be eliminated in the near future. We > expect libSystem to provide all the math routines. Of course, if they have > bugs that is a problem. > > Note that the Clang code you reference in the bug isn 't the code used when > targeting Darwin, so it isn't really relevant to that bug. > > Please file a bug with Apple, the library issue sounds like just a bug. > Although it is worth noting that clang/llvm-gcc seem to get it wrong as well, > without calling the library function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug middle-end/32628] [4.3 Regression] bogus integer overflow warning
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2010-04-13 15:48 --- Subject: Bug 32628 Author: ebotcazou Date: Tue Apr 13 15:47:38 2010 New Revision: 158274 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158274 Log: PR middle-end/32628 * c-common.c (pointer_int_sum): Disregard overflow that occured only because of sign-extension change when converting to sizetype here... * fold-const.c (fold_convert_const_int_from_int): ...and not here. * fold-const.c (fold_binary_op_with_conditional_arg): Do not restrict the folding to constants. Remove redundant final conversion. (fold_binary) : Do not associate if the re-association of constants alone overflows. (fold_binary) : Move transformation into BIT_AND_EXPR to the end of the list. (multiple_of_p) : New case. Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/fold-const.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32628
[Bug target/43727] undefined reference to `_restgpr_30_x'
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-04-13 14:30 --- So, my fault. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43727
[Bug target/43727] undefined reference to `_restgpr_30_x'
--- Comment #10 from jakub at gcc dot gnu dot org 2010-04-13 14:18 --- Yes, we sometimes install linker scripts, sometimes symbolic links. E.g. on powerpc64-linux, 32-bit libgcc_s.so is a linker script, while 64-bit libgcc_s.so is a symlink. If you after install overwrite it with a symlink, it won't work properly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43727
[Bug fortran/43747] New: [4.6 Regression] ICE in find_array_section, at fortran/expr.c:1551
After the merge from fortran-exp to trunk the following tests [macbook] f90/bug% cat pr19925_1.f90 INTEGER, PARAMETER :: N=10 INTEGER, PARAMETER :: I(N)=(/(MOD(K,2),K=1,N)/) INTEGER, PARAMETER :: M(N)=I(N:1:-1) END [macbook] f90/bug% cat pr19925_1_db.f90 INTEGER, PARAMETER :: N=10 INTEGER, PARAMETER :: I(N)=(/(MOD(K,2),K=1,N)/) INTEGER, PARAMETER :: M(N)=I(N:1:-1) print *, I(1), M(1), I(N), M(N) END give the same ICE: f951: internal compiler error: in find_array_section, at fortran/expr.c:1551 The backtrace is (gdb) bt #0 fancy_abort (file=0x10097b308 "../../work/gcc/fortran/expr.c", line=1551, function=0x1009fc790 "find_array_section") at ../../work/gcc/diagnostic.c:780 #1 0x000100028728 in find_array_section (expr=0x142ed3160, ref=0x142ed3ae0) at ../../work/gcc/fortran/expr.c:1551 #2 0x00010002ae5b in simplify_const_ref (p=) at ../../work/gcc/fortran/expr.c:1642 #3 0x00010002b81d in gfc_simplify_expr (p=0x142ed3160, type=0) at ../../work/gcc/fortran/expr.c:1917 #4 0x00010002bb4b in simplify_parameter_variable (p=0x142ed2c20, type=0) at ../../work/gcc/fortran/expr.c:1785 #5 0x00010002abd8 in gfc_reduce_init_expr (expr=0x142ed2c20) at ../../work/gcc/fortran/expr.c:2620 #6 0x00010002ac39 in gfc_match_init_expr (result=0x7fff5fbfd340) at ../../work/gcc/fortran/expr.c:2663 #7 0x00010001d96c in gfc_match_data_decl () at ../../work/gcc/fortran/decl.c:1858 #8 0x000100063ea2 in match_word (str=, subr=0x10001cae0 , old_locus=0x7fff5fbfd3d0) at ../../work/gcc/fortran/parse.c:65 #9 0x00010006472d in decode_statement () at ../../work/gcc/fortran/parse.c:284 #10 0x000100065e65 in next_statement () at ../../work/gcc/fortran/parse.c:722 #11 0x0001000672d0 in parse_spec (st=) at ../../work/gcc/fortran/parse.c:2578 #12 0x0001000698cd in parse_progunit (st=ST_ARITHMETIC_IF) at ../../work/gcc/fortran/parse.c:3849 #13 0x00010006a97c in gfc_parse_file () at ../../work/gcc/fortran/parse.c:4283 #14 0x0001000a4bcc in gfc_be_parse_file (set_yydebug=) at ../../work/gcc/fortran/f95-lang.c:239 #15 0x0001006da71b in toplev_main (argc=2, argv=0x7fff5fbfd958) at ../../work/gcc/toplev.c:1053 #16 0x00011014 in start () Note that before the merge trunk gave [macbook] f90/bug% time gfcp pr19925_1.f90 384.017u 1.170s 6:29.56 98.8% 0+0k 1+26io 0pf+0w [macbook] f90/bug% time gfcp pr19925_1_db.f90 pr19925_1_db.f90:2.27: INTEGER, PARAMETER :: I(N)=(/(MOD(K,2),K=1,N)/) 1 Fatal Error: The number of elements in the array constructor at (1) requires an increase of the allowed 65535 upper limit. See -fmax-array-constructor option 383.576u 1.089s 6:29.27 98.8% 0+0k 0+8io 0pf+0w while branch fortran-exp revision 157955 gave [macbook] f90/bug% time /opt/gcc/gcc4.5f/bin/gfortran pr19925_1.f90 2.845u 0.193s 0:03.72 81.4% 0+0k 2+26io 0pf+0w [macbook] f90/bug% a.out [macbook] f90/bug% time /opt/gcc/gcc4.5f/bin/gfortran pr19925_1_db.f90 2.938u 0.198s 0:03.23 96.5% 0+0k 0+8io 0pf+0w [macbook] f90/bug% a.out 1 0 0 1 The regression is probably due to the last patch to fix the compilation of pr34554. -- Summary: [4.6 Regression] ICE in find_array_section, at fortran/expr.c:1551 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: x86_64-apple-darwin10 GCC host triplet: x86_64-apple-darwin10 GCC target triplet: x86_64-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43747
[Bug target/43727] undefined reference to `_restgpr_30_x'
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-04-13 14:10 ---
(In reply to comment #7)
> Is the libgcc_s.so the link finds a linker script?
> You can use -Wl,-M,--verbose to see what is going on.
No, it doesn't seem to.
START GROUP
LOAD /lib/libc.so.6
LOAD /usr/lib/libc_nonshared.a
LOAD /lib/ld.so.1
END GROUP
LOAD /usr/lib/gcc/powerpc64-suse-linux/4.5/libgcc_s.so
LOAD /usr/lib/gcc/powerpc64-suse-linux/4.5/crtendS.o
LOAD /usr/lib/gcc/powerpc64-suse-linux/4.5/../../../../lib/crtn.o
/tmp> ls -l /usr/lib/gcc/powerpc64-suse-linux/4.5/libgcc_s.so
lrwxrwxrwx 1 root root 18 2010-04-07 18:18
/usr/lib/gcc/powerpc64-suse-linux/4.5/libgcc_s.so -> /lib/libgcc_s.so.1
do we now install linker-scripts for libgcc_s.so? If so I have to fixup our
install procedure as I am simply doing
# Move libgcc_s around
rm -f $RPM_BUILD_ROOT/%{_lib}/libgcc_s.so
ln -sf
/%{_lib}/libgcc_s.so.%{libgcc_s}$RPM_BUILD_ROOT{versmainlibdir}/libgcc_s.so
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43727
[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90
--- Comment #12 from dominiq at lps dot ens dot fr 2010-04-13 14:09 --- A few additional notes: (1) with revision 158105 reverted, the test gcc.dg/tree-ssa/reassoc-19.c fails with -m32, but passes with -m64. (2) revision 158265 with/without revision 158105 reverted (after some surgery to replace plus_negates with broken_up_subtracts) also miscompiles doduc.f90. (3) Following comment #10, is it possible to rule out a critical loss of precision due to the reassociation? (4) From Jerry Delisle, the diff before and after r158105 on fedora is $ diff s33022.s.before s33022.s.after 315c315 < subsd 296(%rsp), %xmm14 --- > subsd 288(%rsp), %xmm14 321c321 < subsd 288(%rsp), %xmm14 --- > subsd 296(%rsp), %xmm14 458c458 < xorpd .LC12(%rip), %xmm12 --- > mulsd 384(%rsp), %xmm15 461,462d460 < mulsd 384(%rsp), %xmm15 < subsd 368(%rsp), %xmm12 467d464 < mulsd 232(%rsp), %xmm12 499,501c496,498 < movsd 296(%rsp), %xmm3 < subsd 272(%rsp), %xmm3 < subsd %xmm12, %xmm15 --- > movsd 368(%rsp), %xmm3 > xorpd .LC12(%rip), %xmm3 > subsd %xmm12, %xmm3 504c501 < mulsd %xmm8, %xmm3 --- > mulsd 232(%rsp), %xmm3 505a503,506 > subsd %xmm3, %xmm15 > movsd 296(%rsp), %xmm3 > subsd 272(%rsp), %xmm3 > mulsd %xmm8, %xmm3 -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||matz at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
[Bug target/43727] undefined reference to `_restgpr_30_x'
--- Comment #8 from marcus at jet dot franken dot de 2010-04-13 14:08 --- $ file /usr/lib/gcc/powerpc64-suse-linux/4.5/libgcc_s.so /usr/lib/gcc/powerpc64-suse-linux/4.5/libgcc_s.so: symbolic link to `/lib/libgcc_s.so.1' $ file /lib/libgcc_s.so.1 /lib/libgcc_s.so.1: ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, with unknown capability 0x4100 = 0x13676e75, with unknown capability 0x1 = 0xb0401, stripped $ (its from the gcc45 system compiler in opensuse Factory on ppc32 bit) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43727
[Bug middle-end/43730] [4.5/4.6 Regression] internal compiler error: in expand_builtin_interclass_mathfn, at builtins.c:2313
--- Comment #7 from matz at gcc dot gnu dot org 2010-04-13 13:54 --- Fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43730
[Bug middle-end/43730] [4.5/4.6 Regression] internal compiler error: in expand_builtin_interclass_mathfn, at builtins.c:2313
--- Comment #6 from matz at gcc dot gnu dot org 2010-04-13 13:47 --- Subject: Bug 43730 Author: matz Date: Tue Apr 13 13:47:11 2010 New Revision: 158270 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158270 Log: PR middle-end/43730 * builtins.c (expand_builtin_interclass_mathfn): Also create a register if the predicate doesn't match. testsuite/ * gcc.dg/pr43730.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/pr43730.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/builtins.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43730
[Bug middle-end/43730] [4.5/4.6 Regression] internal compiler error: in expand_builtin_interclass_mathfn, at builtins.c:2313
--- Comment #5 from matz at gcc dot gnu dot org 2010-04-13 13:35 --- Subject: Bug 43730 Author: matz Date: Tue Apr 13 13:35:30 2010 New Revision: 158268 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158268 Log: PR middle-end/43730 * builtins.c (expand_builtin_interclass_mathfn): Also create a register if the predicate doesn't match. testsuite/ * gcc.dg/pr43730.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr43730.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43730
[Bug target/43727] undefined reference to `_restgpr_30_x'
--- Comment #7 from jakub at gcc dot gnu dot org 2010-04-13 12:43 --- Is the libgcc_s.so the link finds a linker script? You can use -Wl,-M,--verbose to see what is going on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43727
[Bug target/43727] undefined reference to `_restgpr_30_x'
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-13 12:34 --- I can reproduce it. /tmp> g++ -Os -shared -o libhello.so -Wl,-z,defs -fPIC hello.c -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64-suse-linux/4.5/lto-wrapper Target: powerpc64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.5 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.5 --enable-linux-futex --without-system-libunwind --enable-gold --with-plugin-ld=/usr/bin/gold --with-cpu=default32 --enable-secureplt --with-long-double-128 --build=powerpc64-suse-linux Thread model: posix gcc version 4.5.0 20100331 (experimental) [trunk revision 157870] (SUSE Linux) COLLECT_GCC_OPTIONS='-Os' '-shared' '-o' 'libhello.so' '-fPIC' '-v' '-shared-libgcc' /usr/lib/gcc/powerpc64-suse-linux/4.5/cc1plus -quiet -v -D_GNU_SOURCE -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix hello.c -msecure-plt -quiet -dumpbase hello.c -auxbase hello -Os -version -fPIC -o /tmp/ccwdek6v.s GNU C++ (SUSE Linux) version 4.5.0 20100331 (experimental) [trunk revision 157870] (powerpc64-suse-linux) compiled by GNU C version 4.5.0 20100331 (experimental) [trunk revision 157870], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/lib/gcc/powerpc64-suse-linux/4.5/../../../../powerpc64-suse-linux/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.5 /usr/include/c++/4.5/powerpc64-suse-linux /usr/include/c++/4.5/backward /usr/local/include /usr/lib/gcc/powerpc64-suse-linux/4.5/include /usr/lib/gcc/powerpc64-suse-linux/4.5/include-fixed /usr/include End of search list. GNU C++ (SUSE Linux) version 4.5.0 20100331 (experimental) [trunk revision 157870] (powerpc64-suse-linux) compiled by GNU C version 4.5.0 20100331 (experimental) [trunk revision 157870], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: bb776fa20ad0aa28b65c57db982d18c1 COLLECT_GCC_OPTIONS='-Os' '-shared' '-o' 'libhello.so' '-fPIC' '-v' '-shared-libgcc' as -a32 -K PIC -mppc -many -V -Qy -o /tmp/ccE5Vz4Y.o /tmp/ccwdek6v.s GNU assembler version 2.20.0 (powerpc-suse-linux) using BFD version (GNU Binutils; openSUSE Factory) 2.20.0.20100122-4.7 COMPILER_PATH=/usr/lib/gcc/powerpc64-suse-linux/4.5/:/usr/lib/gcc/powerpc64-suse-linux/4.5/:/usr/lib/gcc/powerpc64-suse-linux/:/usr/lib/gcc/powerpc64-suse-linux/4.5/:/usr/lib/gcc/powerpc64-suse-linux/ LIBRARY_PATH=/usr/lib/gcc/powerpc64-suse-linux/4.5/:/usr/lib/gcc/powerpc64-suse-linux/4.5/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/powerpc64-suse-linux/4.5/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-Os' '-shared' '-o' 'libhello.so' '-fPIC' '-v' '-shared-libgcc' /usr/lib/gcc/powerpc64-suse-linux/4.5/collect2 --build-id --eh-frame-hdr -V -Qy -shared -m elf32ppclinux -o libhello.so /usr/lib/gcc/powerpc64-suse-linux/4.5/../../../../lib/crti.o /usr/lib/gcc/powerpc64-suse-linux/4.5/crtbeginS.o -L/usr/lib/gcc/powerpc64-suse-linux/4.5 -L/usr/lib/gcc/powerpc64-suse-linux/4.5/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/powerpc64-suse-linux/4.5/../../.. -z defs /tmp/ccE5Vz4Y.o -lstdc++ -lm -lgcc_s -lc -lgcc_s /usr/lib/gcc/powerpc64-suse-linux/4.5/crtendS.o /usr/lib/gcc/powerpc64-suse-linux/4.5/../../../../lib/crtn.o GNU ld (GNU Binutils; openSUSE Factory) 2.20.0.20100122-4.7 Supported emulations: elf32ppclinux elf32ppc elf32ppcsim elf64ppc elf32_spu /tmp/ccE5Vz4Y.o: In function `hello()': hello.c:(.text+0x30): undefined reference to `_restgpr_30_x' collect2: ld returned 1 exit status -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-13 12:34:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43727
[Bug bootstrap/43733] bootstrap fails on Solaris 10 x86 with GNU as 2.15 and --with-arch=core2
--- Comment #21 from redi at gcc dot gnu dot org 2010-04-13 12:26 --- more accurate summary -- redi at gcc dot gnu dot org changed: What|Removed |Added Summary|bootstrap fails building|bootstrap fails on Solaris |libgfortran on Solaris x86 |10 x86 with GNU as 2.15 and |with GNU as |--with-arch=core2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug bootstrap/43737] Bootstrap broken at -O3
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-13 12:24 --- really -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43737
[Bug bootstrap/43737] Bootstrap broken at -O3
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-13 12:23 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43737
[Bug bootstrap/43737] Bootstrap broken at -O3
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-13 12:23 --- Subject: Bug 43737 Author: rguenth Date: Tue Apr 13 12:23:17 2010 New Revision: 158264 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158264 Log: 2010-04-13 Richard Guenther PR bootstrap/43737 * builtins.c (c_readstr): Fix assert. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43737
[Bug middle-end/43730] [4.5/4.6 Regression] internal compiler error: in expand_builtin_interclass_mathfn, at builtins.c:2313
--- Comment #4 from matz at gcc dot gnu dot org 2010-04-13 11:59 --- No, we shouldn't unconditionally create REGs if the target isn't one, but rather only if it doesn't match the predicate. Like so, which I'm testing right now: Index: builtins.c === --- builtins.c (revision 158160) +++ builtins.c (working copy) @@ -2316,7 +2316,8 @@ expand_builtin_interclass_mathfn (tree e tree orig_arg = arg; /* Make a suitable register to place result in. */ if (!target - || GET_MODE (target) != TYPE_MODE (TREE_TYPE (exp))) + || GET_MODE (target) != TYPE_MODE (TREE_TYPE (exp)) + || !insn_data[icode].operand[0].predicate (target, GET_MODE (target))) target = gen_reg_rtx (TYPE_MODE (TREE_TYPE (exp))); gcc_assert (insn_data[icode].operand[0].predicate -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-04-12 18:38:24 |2010-04-13 11:59:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43730
[Bug middle-end/43735] [4.6 Regression] FAIL: gcc.dg/guality/inline-params.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-13 11:51 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43735
[Bug middle-end/43735] [4.6 Regression] FAIL: gcc.dg/guality/inline-params.c
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-13 11:51 --- Subject: Bug 43735 Author: rguenth Date: Tue Apr 13 11:50:54 2010 New Revision: 158263 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158263 Log: 2010-04-13 Richard Guenther PR testsuite/43735 * gcc.dg/guality/inline-params.c: Remove -fwhopr XPASS. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/guality/inline-params.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43735
[Bug other/31400] enable static linking of support libraries through -static-libXY
--- Comment #19 from iains at gcc dot gnu dot org 2010-04-13 11:37 --- Subject: Bug 31400 Author: iains Date: Tue Apr 13 11:37:34 2010 New Revision: 158262 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158262 Log: gcc/fortran: 2010-04-13 Iain Sandoe PR bootstrap/31400 * gfortranspec.c (lookup_option): Check for -static and return OPTION_static. (lang_specific_driver): Break when OPTION_static is discovered. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortranspec.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31400
[Bug middle-end/43735] [4.6 Regression] FAIL: gcc.dg/guality/inline-params.c
--- Comment #2 from jamborm at gcc dot gnu dot org 2010-04-13 11:31 ---
(In reply to comment #1)
> Confirmed.
>
> I think the testcase is broken. We now force always-inline functions to
> be inlined during early inlining (which you can't turn off completely
> now, similar to IPA inlining before the patch). So we hit
>
> /* IPA-SRA removes the arguments as dead, so we don't see their values, early
>inlining inlines the functions too early to test the real IPA passes (such
>as IPA-CP). */
>
> The testcase misses a return 0. I don't know the guality too much, where
> do the execute XPASSes / FAILs come from?
As far as I remember, IPA-CP does not store the known constant values
of removed parameters in the debug info.
>
> If I remove the always-inline attributes the tests all PASS / XFAIL.
Given the new semantics of the attribute, this is probably the right
thing to do.
>
> If I remove the { "-fwhopr" } from the dg-xfail line all works as well.
>
I recall that the WHOPR XPASS was also a bit of a mystery to me but I
do not remember whether I found out why it took place. Anyway, I
believe that if you make it XFAIL, it is OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43735
[Bug bootstrap/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as
--- Comment #20 from redi at gcc dot gnu dot org 2010-04-13 11:21 --- oops - I didn't mean to set the component back to libfortran, that must have happened when I refreshed the page and my browser "helpfully" kept that selected. I've reverted it to bootstrap I don't think it should be closed: the installation docs for Solaris x86 recommend to use the default binutils 2.15 and say it works fine, but that's not the case if you use --with-arch=core2, that should be documented (or even better, fixed) -- redi at gcc dot gnu dot org changed: What|Removed |Added Component|libfortran |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug bootstrap/43737] Bootstrap broken at -O3
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-13 11:20 ---
Well. There is
pretmp.2458_440 = c[2]{lb: 0 sz: 8};
...
c[2] = D.84046_29;
in a possibly dead code region dominated by
if (pretmp.2460_55 > 16)
goto ;
else
goto ;
where pretmp.2460_55 is (unsigned int)mode_size[mode_10(D)]. Thus,
the loop is peeled completely.
As we have
gcc_assert (j <= 2 * HOST_BITS_PER_WIDE_INT);
if (ch)
ch = (unsigned char) str[i];
c[j / HOST_BITS_PER_WIDE_INT] |= ch << (j % HOST_BITS_PER_WIDE_INT);
you can see that for j == 2 * HOST_BITS_PER_WIDE_INT we end up
accessing c[2]. In fact the assert looks wrong just for that reason.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43737
[Bug target/43613] Some architecture-dependent codes
--- Comment #6 from aflyhorse at foxmail dot com 2010-04-13 10:58 --- (In reply to comment #5) > I don't get why you closed this bug. Anyways if you have a patch, post it to > gcc-patc...@. Sorry, I see nobody concerns this, and I'm more anxious about how to port the libgcj (especially boehm-gc) to win64, so I closed it. Maybe i should use the diff to release a patch for it~ (Since I'm a newbee I've never done so :P) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613
[Bug testsuite/43739] [4.5 Regression] FAIL: gcc.dg/pr43643.c (test for excess errors)
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org Summary|FAIL: gcc.dg/pr43643.c (test|[4.5 Regression] FAIL: |for excess errors) |gcc.dg/pr43643.c (test for ||excess errors) Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43739
[Bug middle-end/43740] [4.5 Regression] FAIL: gcc.dg/tree-ssa/20031015-1.c (internal compiler error)
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-13 10:37 --- Can you bisect the few commits that happened inbetween? Like reverting the fixes for PRs 43679 and/or 43661, 43642? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43740
[Bug rtl-optimization/43742] [4.6 Regression] web.c/union_match_dups segfaults for a null *ref on sh-elf
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43742
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #37 from rguenth at gcc dot gnu dot org 2010-04-13 10:29 --- *** Bug 43744 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/43744] SH: Error: pcrel too far
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-13 10:29 --- *** This bug has been marked as a duplicate of 42841 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744
[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as
--- Comment #19 from burnus at gcc dot gnu dot org 2010-04-13 10:12 --- > This looks like a bug in binutils 2.15 Can we thus close the bug? Or remains there something to do in libgfortran? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as
--- Comment #18 from redi at gcc dot gnu dot org 2010-04-13 09:21 --- Instead I've decided to use --with-arch=nocona --with-tune=core2, since that avoids having to deploy a new binutils to every server where I want to deploy gcc -- redi at gcc dot gnu dot org changed: What|Removed |Added Component|bootstrap |libfortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733
[Bug middle-end/43735] [4.6 Regression] FAIL: gcc.dg/guality/inline-params.c
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-13 09:11 ---
Confirmed.
I think the testcase is broken. We now force always-inline functions to
be inlined during early inlining (which you can't turn off completely
now, similar to IPA inlining before the patch). So we hit
/* IPA-SRA removes the arguments as dead, so we don't see their values, early
inlining inlines the functions too early to test the real IPA passes (such
as IPA-CP). */
The testcase misses a return 0. I don't know the guality too much, where
do the execute XPASSes / FAILs come from?
If I remove the always-inline attributes the tests all PASS / XFAIL.
If I remove the { "-fwhopr" } from the dg-xfail line all works as well.
I'm confused.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||jakub at gcc dot gnu dot
||org, jamborm at gcc dot gnu
||dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-04-13 09:11:07
date||
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43735
[Bug rtl-optimization/43742] [4.6 Regression] web.c/union_match_dups segfaults for a null *ref on sh-elf
--- Comment #3 from bernds at codesourcery dot com 2010-04-13 09:09 --- Created an attachment (id=20377) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20377&action=view) A patch to fix the problem This seems to be due to a pattern that uses a "+" constraint in an input-only operand. The attached patch seems to fix it for me; please confirm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43742
[Bug middle-end/43730] [4.5/4.6 Regression] internal compiler error: in expand_builtin_interclass_mathfn, at builtins.c:2313
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-13 09:02 --- Micha - compared to 4.4 we arrive with (gdb) call debug_rtx (target) (mem/c/i:SI (plus:DI (reg/f:DI 54 virtual-stack-vars) (const_int -4 [0xfffc])) [0 result+0 S4 A32]) instead of (gdb) call debug_rtx (target) (reg:SI 59 [ D.1598 ]) which isn't valid for (define_expand "isinfxf2" [(use (match_operand:SI 0 "register_operand" "")) (use (match_operand:XF 1 "register_operand" ""))] "TARGET_USE_FANCY_MATH_387 && TARGET_C99_FUNCTIONS" but we assert that it is. Do we never expect a MEM for target or why were we lucky before? I can obviously "fix" this by Index: builtins.c === --- builtins.c (revision 158225) +++ builtins.c (working copy) @@ -2316,6 +2316,7 @@ expand_builtin_interclass_mathfn (tree e tree orig_arg = arg; /* Make a suitable register to place result in. */ if (!target + || !REG_P (target) || GET_MODE (target) != TYPE_MODE (TREE_TYPE (exp))) target = gen_reg_rtx (TYPE_MODE (TREE_TYPE (exp))); -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||matz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43730
[Bug bootstrap/43737] Bootstrap broken at -O3
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-13 08:44:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43737
[Bug c++/43746] -fmerge-constants and -fmerge-all-constants don't work at AVR target
--- Comment #1 from j at uriah dot heep dot sax dot de 2010-04-13 08:31 --- I think this is essentially a duplicate of bug #21018. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43746
[Bug c++/43746] New: -fmerge-constants and -fmerge-all-constants don't work at AVR target
-fmerge-all-constants and –fmerge-constants don’t work at AVR target. Example: const char text1[] PROGMEM=”Test”; const char text2[] PROGMEM=”Test”; will still produce duplicated “Test” string in generated code. -- Summary: -fmerge-constants and -fmerge-all-constants don't work at AVR target Product: gcc Version: 4.3.5 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tfrancuz at mp dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43746
[Bug c++/43745] New: g++ puts VTABLES in SRAM
On AVR target g++ generates code which copies object’s VTABLES from FLASH
to SRAM wasting the memory. Due to the Harvard architecture of AVR processors
the solution is not trivial. This behavior can be observed in any c++ program
which has object with virtual method, e.g:
Class test
{
virtual void example();
};
The VTABLE of class test will be generated in FLASH and next copied to SRAM,
any reference to virtual example() method will take the method address from
SRAM.
--
Summary: g++ puts VTABLES in SRAM
Product: gcc
Version: 4.3.5
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tfrancuz at mp dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43745
[Bug target/43744] SH: Error: pcrel too far
--- Comment #4 from iwamatsu at nigauri dot org 2010-04-13 08:09 --- Hi, (In reply to comment #3) > Looks that Christian's patch pic-cp.patch > > http://gcc.gnu.org/bugzilla/attachment.cgi?id=19794 > > in PR target/42841 can fix the problem. Could you > please try it? > I confirmed that this problem was revised. Do you have the plan applying this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744
[Bug target/43722] ICE when passing NEON registers using const refrences
--- Comment #7 from liranuna at gmail dot com 2010-04-13 07:43 --- Mikael's patch seems to do that trick as well as producing very nice assembly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43722
