[Bug fortran/28039] Warn when ignoring extra characters in the format specification
--- Comment #7 from burnus at gcc dot gnu dot org 2009-08-27 06:29 --- As the patch was reverted, re-open the PR. Remember to include the example of PR 41152 when submitting the next patch. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28039
[Bug fortran/40823] debug info points to unexpected line
--- Comment #4 from jv244 at cam dot ac dot uk 2009-08-27 06:50 --- changing component since this really looks like a FE issue -- jv244 at cam dot ac dot uk changed: What|Removed |Added Component|debug |fortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40823
[Bug debug/41170] namespace DIE not generated when it contains only a typedef
--- Comment #3 from dodji at gcc dot gnu dot org 2009-08-27 07:05 --- Subject: Bug 41170 Author: dodji Date: Thu Aug 27 07:05:24 2009 New Revision: 151138 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151138 Log: Fix for PR debug/41170 gcc/ChangeLog: PR debug/41770 * dwarf2out.c (get_context_die): Declare this static function. (gen_type_die_with_usage): Make sure a DIE is a generated for the context of a typedef. gcc/testsuite/ChangeLog: PR debug/41770 * debug/dwarf2/namespace-1.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/namespace-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41170
[Bug debug/41170] namespace DIE not generated when it contains only a typedef
--- Comment #4 from dodji at gcc dot gnu dot org 2009-08-27 07:14 --- Fixed in trunk (4.5). -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41170
[Bug lto/41092] WPA doesn't generate unwind information where necessary
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-27 09:17 --- I have a patch. -- 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|NEW |ASSIGNED Last reconfirmed|2009-08-19 06:15:15 |2009-08-27 09:17:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41092
[Bug target/35847] unrecognized option `-march=score7'
--- Comment #3 from liqin at gcc dot gnu dot org 2009-08-27 09:17 --- please download new binutils-2.19.51, it already support score7 option. -- liqin at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35847
[Bug debug/41130] GCC should emit an index of publicly named entities
--- Comment #4 from dodji at gcc dot gnu dot org 2009-08-27 09:31 --- Created an attachment (id=18434) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18434action=view) Updated patch This patch removes the addition fix that was carried by previous patch as that fix was pushed upstream, independently as PR debug/41770 . Adjust tests to pass regtests. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Attachment #18420|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130
[Bug debug/41130] GCC should emit an index of publicly named entities
--- Comment #5 from dodji at gcc dot gnu dot org 2009-08-27 09:33 --- Created an attachment (id=18435) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18435action=view) Oops. Okay, this is the patch I wanted to attach. Not #18434. So the previous comment applies to this entry. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Attachment #18434|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130
[Bug fortran/41177] New: Wrong base-object checks for type-bound procedures
ELEMENTAL type-bound procedures (and in consequence also, for instance, type-bound operators or assignments on arrays) do not work for non-scalar passed-objects (even though the procedures are ELEMENTAL): MODULE m IMPLICIT NONE TYPE t CONTAINS PROCEDURE, PASS :: myproc END TYPE t CONTAINS ELEMENTAL INTEGER FUNCTION myproc (me) CLASS(t), INTENT(IN) :: me myproc = 42 END FUNCTION myproc END MODULE m PROGRAM main USE m IMPLICIT NONE TYPE(t) :: arr(2) PRINT *, arr%myproc () END PROGRAM main [/tmp]# gfortran-dev elemental.f03 -w elemental.f03:23.10: PRINT *, arr%myproc () 1 Error: Passed-object at (1) must be scalar This is a wrongly placed check; actually, on the declaration it should be checked that the passed-object dummy argument is scalar, non-pointer and non-allocatable, but that check is in turn missing; this one is accepted but is illegal: MODULE m IMPLICIT NONE TYPE t CONTAINS PROCEDURE, PASS :: proc1 PROCEDURE, PASS :: proc2 END TYPE t CONTAINS INTEGER FUNCTION proc1 (me) CLASS(t), INTENT(IN) :: me(:) proc1 = 42 END FUNCTION proc1 INTEGER FUNCTION proc2 (me) CLASS(t), INTENT(IN), POINTER :: me proc2 = 42 END FUNCTION proc2 ! ALLOCATABLE scalar can't be checked, but is the same. END MODULE m -- Summary: Wrong base-object checks for type-bound procedures Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: domob at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41177
[Bug fortran/41177] Wrong base-object checks for type-bound procedures
--- Comment #1 from domob at gcc dot gnu dot org 2009-08-27 09:57 --- I will work on this. Janus, how's that also related to PPCs? I'll leave that open for you, if there is anything to correct, also (the 'wrong' check for scalar passed-object is there literally for PPCs, too, but it may be correct there). -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-27 09:57:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41177
[Bug libstdc++/41174] uncaught_exception always returns true
-- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c++ |libstdc++ Ever Confirmed|0 |1 GCC build triplet|same| GCC host triplet|Microsoft Windows XP Home | |Edition, x86 Family 16 Model| |2 Steppin | GCC target triplet|same| Known to fail||4.3.4 4.4.1 4.5.0 Last reconfirmed|-00-00 00:00:00 |2009-08-27 10:37:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
[Bug target/40414] gcc 4.4.0 error at postreload.c:396
--- Comment #14 from nospamname at web dot de 2009-08-27 10:38 --- I compile gcc 4.4.2 20090825 and test. problem is still in. Is this fix in gcc4.4.2 too ?. The mpegvideo.i test case does not compile as-is for me, as the compiler complains about a syntax error: libavcodec/mpegvideo.c:89: error: expected ';', ',' or ')' before 'p' because ffmpeg use cpu specific code, you must configure first for crosscompile.This line is used for the 68k compilers run on cygwin. ./configure --arch=m68k --enable-cross-compile --cross-prefix=m68k-amigaos- --extra-cflags=-mnobitfield -m68060 -- nospamname at web dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40414
[Bug libstdc++/41174] uncaught_exception always returns true
--- Comment #6 from paolo dot carlini at oracle dot com 2009-08-27 10:51 --- Is this related to PR 37477? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
[Bug c++/40146] Unexplained 'anonymous' is used uninitialized in this function warning
--- Comment #4 from caolanm at redhat dot com 2009-08-27 11:17 --- Created an attachment (id=18436) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18436action=view) smaller test-case Here's a smaller one, perturbing nearly any line in this makes the warning go away, various sample lines are commented as such in this 100 line example. Like before... g++ -DTEST -O2 -c -Wall foo.cxx no warnings, while g++ -O2 -c -Wall foo.cxx foo.cxx: In function 'bool demo()': foo.cxx:83: warning: 'anonymous' is used uninitialized in this function foo.cxx:83: note: 'anonymous' was declared here -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40146
[Bug c++/40146] Unexplained 'anonymous' is used uninitialized in this function warning
-- caolanm at redhat dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40146
[Bug c++/40146] Unexplained 'anonymous' is used uninitialized in this function warning
--- Comment #5 from bangerth at gmail dot com 2009-08-27 11:35 --- The warning isn't triggered any more with current mainline. Can someone gives this a try with the current 4.4.x branch? W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40146
[Bug libstdc++/41174] uncaught_exception always returns true
--- Comment #7 from redi at gcc dot gnu dot org 2009-08-27 11:37 --- (In reply to comment #6) Is this related to PR 37477? It looks like a slightly different issue. PR 37477 relates to when uncaught_exception() stops being true and fixing it might need to wait for the resolution to core issue 475. This bug relates to when uncaught_exception() starts being true, and I don't think it depends on issue 475 (although it might make sense to wait for a resolution anyway.) The table in issue 475 would show today's GCC as 1 1 1 1 ABRT and I believe that first 1 is wrong and is the root cause of this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
[Bug fortran/37425] Fortran 2003: GENERIC bindings as operators
--- Comment #4 from domob at gcc dot gnu dot org 2009-08-27 11:43 --- Subject: Bug 37425 Author: domob Date: Thu Aug 27 11:42:56 2009 New Revision: 151140 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151140 Log: 2009-08-27 Daniel Kraft d...@domob.eu PR fortran/37425 * gfortran.h (gfc_expr): Optionally store base-object in compcall value and add a new flag to distinguish assign-calls generated. (gfc_find_typebound_proc): Add locus argument. (gfc_find_typebound_user_op), (gfc_find_typebound_intrinsic_op): Ditto. (gfc_extend_expr): Return if failure was by a real error. * interface.c (matching_typebound_op): New routine. (build_compcall_for_operator): New routine. (gfc_extend_expr): Handle type-bound operators, some clean-up and return if failure was by a real error or just by not finding an appropriate operator definition. (gfc_extend_assign): Handle type-bound assignments. * module.c (MOD_VERSION): Incremented. (mio_intrinsic_op): New routine. (mio_full_typebound_tree): New routine to make typebound-procedures IO code reusable for type-bound user operators. (mio_f2k_derived): IO of type-bound operators. * primary.c (gfc_match_varspec): Initialize new fields in gfc_expr and pass locus to gfc_find_typebound_proc. * resolve.c (resolve_operator): Only output error about no matching interface if gfc_extend_expr did not already fail with an error. (extract_compcall_passed_object): Use specified base-object if present. (update_compcall_arglist): Handle ignore_pass field. (resolve_ordinary_assign): Update to handle extended code for type-bound assignments, too. (resolve_code): Handle EXEC_ASSIGN_CALL statement code. (resolve_tb_generic_targets): Pass locus to gfc_find_typebound_proc. (resolve_typebound_generic), (resolve_typebound_procedure): Ditto. (resolve_typebound_intrinsic_op), (resolve_typebound_user_op): Ditto. (ensure_not_abstract_walker), (resolve_fl_derived): Ditto. (resolve_typebound_procedures): Remove not-implemented error. (resolve_typebound_call): Handle assign-call flag. * symbol.c (find_typebound_proc_uop): New argument to pass locus for error message about PRIVATE, verify that a found procedure is not marked as erraneous. (gfc_find_typebound_intrinsic_op): Ditto. (gfc_find_typebound_proc), (gfc_find_typebound_user_op): New locus arg. 2009-08-27 Daniel Kraft d...@domob.eu PR fortran/37425 * gfortran.dg/impure_assignment_1.f90: Change expected error message. * gfortran.dg/typebound_operator_1.f03: Remove check for not-implemented error and fix problem with recursive assignment. * gfortran.dg/typebound_operator_2.f03: No not-implemented check. * gfortran.dg/typebound_operator_3.f03: New test. * gfortran.dg/typebound_operator_4.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/typebound_operator_3.f03 trunk/gcc/testsuite/gfortran.dg/typebound_operator_4.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/module.c trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/impure_assignment_1.f90 trunk/gcc/testsuite/gfortran.dg/typebound_operator_1.f03 trunk/gcc/testsuite/gfortran.dg/typebound_operator_2.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37425
[Bug fortran/41178] New: Ambiguity checks for type-bound and interface operator calls
This is currently marked TODO in interface.c:gfc_expand_expr/gfc_expand_assign. When looking for a matching interface or type-bound operator, we could always continue looking through all possibilities and see if more than one option is found, in which case we should emit an error (or at least warn about that one of those will be chosen arbitrarily). -- Summary: Ambiguity checks for type-bound and interface operator calls Product: gcc Version: unknown Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: domob at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41178
[Bug fortran/41178] Ambiguity checks for type-bound and interface operator calls
--- Comment #1 from domob at gcc dot gnu dot org 2009-08-27 11:50 --- I take this on. -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-27 11:50:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41178
[Bug fortran/41177] Wrong base-object checks for type-bound procedures
--- Comment #2 from domob at gcc dot gnu dot org 2009-08-27 11:55 --- When this is fixed, we should also add a test-case to check that type-bound assignment does correct dependency-checking (based on elemental_subroutine_3.f90 for instance). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41177
[Bug libstdc++/41174] uncaught_exception always returns true
--- Comment #8 from paolo dot carlini at oracle dot com 2009-08-27 11:59 --- As a general rule, if we are sure about the dependency on a DR, we suspend the PR and remember the DR # in the Summary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
[Bug fortran/28039] Warn when ignoring extra characters in the format specification
--- Comment #8 from burnus at gcc dot gnu dot org 2009-08-27 12:00 --- Subject: Bug 28039 Author: burnus Date: Thu Aug 27 11:59:51 2009 New Revision: 151141 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151141 Log: 2009-08-27 Tobias Burnus bur...@net-b.de PR fortran/28039 * gfortran.dg/fmt_with_extra.f: xfail testcase as patch was * reverted. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/fmt_with_extra.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28039
[Bug fortran/41152] [4.5 Regression] Spurious diagnostic Extraneous characters in format
--- Comment #4 from burnus at gcc dot gnu dot org 2009-08-27 12:04 --- The patch of PR 28093 was reverted -- thus closing as fixed. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41152
[Bug c++/28093] Wrong overload resolution with templates and namespaces
--- Comment #4 from burnus at gcc dot gnu dot org 2009-08-27 12:05 --- For completeness, the committal was for PR fortran/28039 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28093
[Bug fortran/41152] [4.5 Regression] Spurious diagnostic Extraneous characters in format
--- Comment #5 from burnus at gcc dot gnu dot org 2009-08-27 12:06 --- (In reply to comment #4) The patch of PR 28093 was reverted -- thus closing as fixed. Wrong patch PR. The correct one is PR fortran/28039 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41152
[Bug fortran/28039] Warn when ignoring extra characters in the format specification
--- Comment #9 from burnus at gcc dot gnu dot org 2009-08-27 12:11 --- Test case of valid but previously failing code (which I forgot to include in fmt_with_extra.f when xfailing it): SUBROUTINE rw_inp() CHARACTER(len=100) :: line integer :: i5 character(100), parameter :: subchapter = '(79(-),/,5(-), ,A,/,79(-),/)' i5 = 1 READ(*,FMT=(4x,a)) line 7182 FORMAT (a3) 7130 FORMAT (i3) WRITE (6,'(//'' icorr is not correctly transferred. icorr='',i5) ') 42 write(*,subchapter) 'test' END SUBROUTINE rw_inp The last item has the additional problem that the cursor position points to the expanded string and not to the parameter. That's probably a general problem; (the string could also be 'string'//parameter which should also be treated better.) write(*,subchapter) 'test' 1 Warning: Extraneous characters in format at (1) This presumably should be handled in a different PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28039
[Bug driver/41179] New: Documentation for -fno-toplevel-reorder is confusing (and wrong)
Where it says: Enabled at level `-O0'. When disabled explicitly, it also imply `-fno-section-anchors' that is otherwise enabled at `-O0' on some targets. Firstly, imply should be implies. Secondly, what does disabling the option mean (When disabled explicitly...) - does it mean using ftoplevel-reordering (enabling reordering), in which case wouldn't it be better to say When top-level reordering is enabled explicitly... or When -ftoplevel-reordering is used... and be less ambiguous (and avoid the double negative)? Thirdly, it also imply `-fno-section-anchors' that is otherwise enabled at `-O0' on some targets seems to use the opposite interpretation of enabled compared to the paragraph above (unless I'm getting it wrong). What it's trying to say is that -fno-toplevel-reorder implies -fno-section-anchors which is otherwise *disabled* on some targets, i.e. some targets otherwise assume -fsection-anchors). -- Summary: Documentation for -fno-toplevel-reorder is confusing (and wrong) Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: davmac at davmac dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41179
[Bug libstdc++/41174] uncaught_exception always returns true
--- Comment #9 from redi at gcc dot gnu dot org 2009-08-27 12:18 --- (In reply to comment #5) I think the problem is that the uncaught_exception() is true as soon as the memory for the exception has been allocated, but if the exception's copy constructor is elided then happens before entering the exception's constructor. If the exception constructor throws another exception then uncaughtExceptions goes to 2, and never goes back to zero. After re-reading [except.throw] and [except.terminate] I think it is OK to elide the copy of the thrown object into the exception object here: throw e(); This means that uncaught_exception() can be true in the call e::e() *But* if the copy is elided and e::e() throws then std::terminate() should be called. This means the OP's testcase and my one in comment #5 should terminate, rather than exiting normally with std::uncaught_exception()==true This is because of the following in [except.terminate]/1 when the exception handling mechanism, after completing evaluation of the expression to be thrown but before the exception is caught (15.1), calls a function that exits via an uncaught exception, 141 141) For example, if the object being thrown is of a class with a copy constructor, std::terminate() will be called if that copy constructor exits with an exception during a throw. Now, either (A) e::e() happens before completing evaluation of the expression to be thrown and uncaught_exception() should be false during e::e() or (B) the copy is elided and e::e() happens after evaluating completing evaluation. In this case, uncaught_exception() should be true during e::e() but if it exits with an exception then std::terminate() should be called. GCC elides the copy, but does not call std::terminate() if e::e() exits with an exception. I don't think this interpretation will be changed by DR 475 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
[Bug libstdc++/41174] uncaught_exception always returns true
--- Comment #10 from wwashby at earthlink dot net 2009-08-27 14:27 --- (In reply to comment #9) ... when the exception handling mechanism, after completing evaluation of the expression to be thrown but before the exception is caught (15.1), calls a function that exits via an uncaught exception, 141 141) For example, if the object being thrown is of a class with a copy constructor, std::terminate() will be called if that copy constructor exits with an exception during a throw. ... I'm not sure that this applies in this situation. An instance of BadE is constructed because it is thrown, but BadE::BadE does not [exit] via an uncaught exception. It both throws and catches an exception, and then returns normally. There is still an uncaught exception when BadE::BadE exits, but it is the one that caused BadE to be constructed, not the one that BadE::BadE has thrown (and caught). -- wwashby at earthlink dot net changed: What|Removed |Added CC||wwashby at earthlink dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
[Bug lto/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-08-27 14:35 --- Weird. A trigger for the failure with -flto is the removal of a dead store in container_rand_regression_testCntnr::assignment_operator(). We remove tmp.D.3238.D.3239.D.3240.D.3090.D.3046.D.3014._vptr.hash_load_check_resize_trigger = _ZTVN10__gnu_pbds6detail15gp_ht_map_data_INS_4test10basic_typeES3_NS2_4hashESt8equal_toIS3_EN9__gnu_cxx15throw_allocatorIS3_EELb0ENS2_27direct_mod_range_hashing_t_IS9_EENS2_21quadratic_probe_fn_t_IS3_S9_EENS_27hash_standard_resize_policyINS2_25hash_prime_size_policy_t_ENS2_33hash_load_check_resize_trigger_t_IS9_Lm1ELm8ELm1ELm2ELb1EEELb1Em[2]; at the beginning of BB 21. If you retain that store then this will be the only assembly code difference and the segfault disappears. Reduced flags: -O2 -fno-tree-pre -fno-ivopts -fno-tree-loop-optimize -fno-dse -fno-gcse -fno-tree-sink -fno-tree-dominator-opts -fno-tree-vrp -fno-tree-fre either specifying -fno-strict-aliasing or -fno-tree-dse also fixes the segfault. The funny thing is that trunk (or the branch w/o -flto) also removes that store. I'll attach a slightly reduced testcase momentarily (it just reduces the amount of instantiations, not the amount of source). The testcase is rather awkward in that it relies on randomness to perform the operations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
[Bug lto/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-08-27 14:36 --- Created an attachment (id=18437) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18437action=view) testcase, simplified -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
[Bug c/10676] Using unnamed fields in initializers
--- Comment #11 from jan dot cornelis at gmail dot com 2009-08-27 14:57
---
An example program that shows 3 different methods. Only one works (see comment)
As I used the names for each field, I assumed that all 3 examples should work.
#include inttypes.h
#include stdio.h
struct a_t {
uint16_t a;
uint16_t b;
union {
uint8_t c;
uint16_t d;
};
};
#if (1)
struct a_t alfa = {
.a = 1,
.b = 2,
.c = 3, //Will not work
};
#elif (0)
struct a_t alfa = {
.a = 1,
.b = 2,
{.c = 3}, //works
};
#elif (0)
struct a_t alfa = {
.a = 1,
{.c= 2}, //Does not work
.b = 3,
}
#endif
int main(void)
{
//alfa.c = 4;
//alfa.d = 5;
printf(%20s:%d\n,alfa.a,alfa.a);
printf(%20s:%d\n,alfa.b,alfa.b);
printf(%20s:%d\n,alfa.c,alfa.c);
printf(%20s:%d\n,alfa.d,alfa.d);
return 0;
}
--
jan dot cornelis at gmail dot com changed:
What|Removed |Added
CC||jan dot cornelis at gmail
||dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676
[Bug libstdc++/41174] uncaught_exception always returns true
--- Comment #11 from redi at gcc dot gnu dot org 2009-08-27 15:19 --- (In reply to comment #10) I'm not sure that this applies in this situation. An instance of BadE is constructed because it is thrown, but BadE::BadE does not [exit] via an uncaught exception. It both throws and catches an exception, and then returns normally. There is still an uncaught exception when BadE::BadE exits, but it is the one that caused BadE to be constructed, not the one that BadE::BadE has thrown (and caught). No, in [except.handle]/16 the standard says The exception being handled is rethrown if control reaches the end of a handler of the function-try-block of a constructor or destructor. You cannot swallow exceptions in a constructor's function-try-block, they will be rethrown. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
[Bug fortran/40823] debug info points to unexpected line
--- Comment #5 from jv244 at cam dot ac dot uk 2009-08-27 15:35 --- more debug info .. if I declare S1 to be a function instead of a subroutine, lineno is also correct anybody with [parse.]c experience willing to take over ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40823
[Bug lto/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-08-27 15:43 ---
In fact the code generated by the C++ frontend (or the library) looks bogus.
other.1157_15 = (const struct hash_eq_fn *) D.107435_2;
this.1158_16 = (struct hash_eq_fn *) D.107436_4;
other.1161_17 = (struct equal_to *) other.1157_15;
this.1162_18 = (struct equal_to *) this.1158_16;
__tmp = *this.1162_18;
*this.1162_18 = *other.1161_17;
*other.1161_17 = __tmp;
this swaps the first byte(!) of the struct which contains the vtable pointer.
In fact gp_hash_table::swap(gp_hash_table) seems to cause this. Forcing
to not inline that function fixes the issue as well.
(so the dead store really is not dead - but only because of that bogus swap).
Thus, things like
void
_M_swap(_Hash_code_base __x)
{
std::swap(_M_extract, __x._M_extract);
std::swap(_M_eq, __x._M_eq);
std::swap(_M_h1, __x._M_h1);
std::swap(_M_h2, __x._M_h2);
}
protected:
_ExtractKey _M_extract;
_Equal _M_eq;
_H1 _M_h1;
_H2 _M_h2;
};
seem to corrupt the vtable pointer as the empty function classes are
tail-packed into that field. OTOH std::swap should do nothing for
empty classes, but instead it does
;; Function void std::swap(_Tp, _Tp) [with _Tp =
std::equal_to__gnu_pbds::test::basic_type] (null)
;; enabled by -tree-original
{
struct equal_to __tmp;
struct equal_to __tmp;
cleanup_point Unknown tree: expr_stmt
(void) (__tmp = TARGET_EXPR D.100064, *(const struct equal_to ) (const
struct equal_to *) __a)
;
cleanup_point Unknown tree: expr_stmt
(void) (*(struct equal_to *) __a = *(const struct equal_to ) (const struct
equal_to *) __b)
;
cleanup_point Unknown tree: expr_stmt
(void) (*(struct equal_to *) __b = *(const struct equal_to ) (const struct
equal_to *) __tmp)
;
}
bah. Paolo, who is at fault here? The library or the frontend? The
issue must be latent on trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||paolo dot carlini at oracle
||dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
[Bug libstdc++/39238] trunk revision 144279 - cfenv:54: error: �::fenv_t� has not been declared
--- Comment #9 from vzapolskiy at gmail dot com 2009-08-27 15:59 --- Created an attachment (id=18438) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18438action=view) proposed patch for the problem resolution on gcc-4_4-branch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39238
[Bug lto/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
--- Comment #10 from paolo dot carlini at oracle dot com 2009-08-27 16:00 --- Richard, I have no idea, at the moment. Frankly however, I know, or at least strongly suspect basing on past and still open issues, that pb_ds cannot be fully trusted, isn't really maintained as it should and unfortunately the original author isn't available anymore. Sorry, but I don't think I'm going to spend much time on this issue or anything having to do with this ext/ code, for that matter. I'm CC-ing Benjamin - for sure he knows the code much better than me - just for his information. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC|paolo dot carlini at oracle |bkoz at redhat dot com |dot com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
[Bug libstdc++/39238] trunk revision 144279 - cfenv:54: error: �::fenv_t� has not been declared
--- Comment #10 from vzapolskiy at gmail dot com 2009-08-27 16:00 --- I have encountered the same problem with reverse cross compilation of gcc-4.3 branch on Linux for powerpc target. The problem was introduced in #38000 (revision 143194), and safe solution is just to revert the changes on the next files: * libstdc++-v3/include/c_global/cfenv * libstdc++-v3/include/tr1/cfenv * libstdc++-v3/include/tr1_impl/cfenv * libstdc++-v3/include/c_compatibility/fenv.h Proposed patch for gcc-4_4-branch (revision 151142) is attached. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39238
[Bug fortran/40823] debug info points to unexpected line
--- Comment #6 from jv244 at cam dot ac dot uk 2009-08-27 16:01 --- this is bold guess at a patch, which does fix the lineno info for this testcase, but no idea if this is even remotely correct. Based on the observation that gfc_match_function_decl sets declared_at, but gfc_match_subroutine does not. Index: decl.c === --- decl.c (revision 151059) +++ decl.c (working copy) @@ -5047,7 +5047,10 @@ match is_bind_c; char peek_char; bool allow_binding_name; + locus old_loc; + old_loc = gfc_current_locus; + if (gfc_current_state () != COMP_NONE gfc_current_state () != COMP_INTERFACE gfc_current_state () != COMP_CONTAINS) @@ -5147,6 +5150,8 @@ /* Warn if it has the same name as an intrinsic. */ warn_intrinsic_shadow (sym, false); + sym-declared_at=old_loc; + return MATCH_YES; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40823
[Bug lto/41058] FAIL: ext/pb_ds/regression/hash_data_map_rand.cc
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-08-27 16:08 --- Thanks paolo. It is btw _ZN10__gnu_pbds13gp_hash_tableINS_4test10basic_typeES2_NS1_4hashESt8equal_toIS2_ENS1_27direct_mod_range_hashing_t_IN9__gnu_cxx15throw_allocatorIS2_NS1_21quadratic_probe_fn_t_IS2_S9_EENS_27hash_standard_resize_policyINS1_25hash_prime_size_policy_t_ENS1_33hash_load_check_resize_trigger_t_IS9_Lm1ELm8ELm1ELm2ELb1EEELb1EmEELb0ES9_E4swapERSI_ that has this issue. That is, basic_hash_table...::swap which eventually ends up - somewhere (it's a maze in that libstdc++!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41058
[Bug rtl-optimization/40861] [4.4/4.5 Regression] ICE in simplify_subreg, at simplify-rtx.c:4981
--- Comment #3 from ubizjak at gmail dot com 2009-08-27 16:21 --- Backtrace with current SVN: #1 0x0076991d in simplify_subreg (outermode=SImode, op=0x728a68a0, innermode=DImode, byte=4294967280) at ../../gcc-svn/trunk/gcc/simplify-rtx.c:4982 #2 0x00769b3e in simplify_gen_subreg (outermode=12901752, op=0x1376, innermode=12905920, byte=4) at ../../gcc-svn/trunk/gcc/simplify-rtx.c:5286 #3 0x00769b3e in simplify_gen_subreg (outermode=12901752, op=0x1376, innermode=12905920, byte=4) at ../../gcc-svn/trunk/gcc/simplify-rtx.c:5286 #4 0x00b07848 in if_then_else_cond (x=0x728a69c0, ptrue=0x7fffdb90, pfalse=0x7fffdb80) at ../../gcc-svn/trunk/gcc/combine.c:7979 #5 0x00b07619 in if_then_else_cond (x=0x728a6a20, ptrue=0x7fffdc28, pfalse=0x7fffdc38) at ../../gcc-svn/trunk/gcc/combine.c:7864 #6 0x00b0f037 in combine_simplify_rtx (x=0x728a6a20, op0_mode=SImode, in_dest=0) at ../../gcc-svn/trunk/gcc/combine.c:4629 #7 0x00b115ed in subst (x=0x8, from=value optimized out, to=0x728a68e0, in_dest=0, unique_copy=17) at ../../gcc-svn/trunk/gcc/combine.c:4568 #8 0x00b113a8 in subst (x=0x728a6a40, from=0x728a6860, to=0x728a68e0, in_dest=value optimized out, ---Type return to continue, or q return to quit--- unique_copy=value optimized out) at ../../gcc-svn/trunk/gcc/combine.c:4506 #9 0x00b1129a in subst (x=0x72a67d10, from=0x728a6860, to=0x728a68e0, in_dest=value optimized out, unique_copy=value optimized out) at ../../gcc-svn/trunk/gcc/combine.c:4433 byte argument, passed to simplify_subreg in frame #1 is a bit high for current state of the art. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40861
[Bug libfortran/41169] [4.5 regression] libgfortran fails to build on Solaris 10+: '_Imaginary_I' undeclared
--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2009-08-27 16:25 --- Subject: Re: [4.5 regression] libgfortran fails to build on Solaris 10+: '_Imaginary_I' undeclared joseph at codesourcery dot com writes: There is no use in keeping definitions relating to imaginary types when GCC doesn't implement them, and the uses of imaginary types are extremely limited (as far as I can tell, they are only useful for building up complex values with exact control of infinities, NaNs and signed zeros in each component). Ok, thanks. So I'll implement my manual hack in fixincludes and submit that patch once I'm ready. I'll probably try to get a fix into OpenSolaris for CR 6549313 http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6549313 so the fix will become unnecessary in the future. What I don't fully understand yet is whether imaginary support in GCC isn't/won't be there simply because it's been removed from C99 or nobody thinks the work to implement it is worthwile. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41169
[Bug lto/41092] WPA doesn't generate unwind information where necessary
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-27 16:10 --- Subject: Bug 41092 Author: rguenth Date: Thu Aug 27 16:10:15 2009 New Revision: 151143 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151143 Log: 2009-08-27 Richard Guenther rguent...@suse.de PR lto/41092 * lto-streamer-out.c (output_eh_regions): Always output a eh region if exceptions are enabled. Modified: branches/lto/gcc/ChangeLog.lto branches/lto/gcc/lto-streamer-out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41092
[Bug lto/41092] WPA doesn't generate unwind information where necessary
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-27 16:11 --- Fixed. -- 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=41092
[Bug libstdc++/39238] trunk revision 144279 - cfenv:54: error: �::fenv_t� has not been declared
--- Comment #11 from paolo dot carlini at oracle dot com 2009-08-27 16:09 --- (In reply to comment #10) I have encountered the same problem with reverse cross compilation of gcc-4.3 branch on Linux for powerpc target. The problem was introduced in #38000 (revision 143194), and safe solution is just to revert the changes on the next files: The change is not safe at all, unless you can convincingly explain why reverting these bits does not break again 38000. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39238
[Bug rtl-optimization/33928] [4.3/4.4/4.5 Regression] 30% performance slowdown in floating-point code caused by r118475
--- Comment #111 from lucier at math dot purdue dot edu 2009-08-27 17:02 --- I can compile gambit 4.1.2 with -fschedule-insns except for the function noted in PR41164. On model name : Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz with gcc version 4.5.0 20090803 (experimental) [trunk revision 150373] (GCC) the times with -fschedule-insns are (time (direct-fft-recursive-4 a table)) 144 ms cpu time (144 user, 0 system) (time (inverse-fft-recursive-4 a table)) 136 ms cpu time (136 user, 0 system) and the times without -fschedule-insns are (time (direct-fft-recursive-4 a table)) 168 ms cpu time (168 user, 0 system) (time (inverse-fft-recursive-4 a table)) 172 ms cpu time (172 user, 0 system) That's a pretty big improvement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
[Bug rtl-optimization/40861] [4.4/4.5 Regression] ICE in simplify_subreg, at simplify-rtx.c:4981
--- Comment #4 from ubizjak at gmail dot com 2009-08-27 17:19 ---
Patch in testing:
--cut here--
Index: simplify-rtx.c
===
--- simplify-rtx.c (revision 151142)
+++ simplify-rtx.c (working copy)
@@ -5263,6 +5263,7 @@ simplify_subreg (enum machine_mode outer
GET_MODE_BITSIZE (innermode) = (2 * GET_MODE_BITSIZE (outermode))
CONST_INT_P (XEXP (op, 1))
(INTVAL (XEXP (op, 1)) (GET_MODE_BITSIZE (outermode) - 1)) == 0
+ INTVAL (XEXP (op, 1)) = 0
INTVAL (XEXP (op, 1)) GET_MODE_BITSIZE (innermode)
byte == subreg_lowpart_offset (outermode, innermode))
{
--cut here--
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40861
[Bug rtl-optimization/41164] Unable to find spill register with -fschedule-insns
--- Comment #2 from ubizjak at gmail dot com 2009-08-27 17:33 --- Duplicate of PR24319. *** This bug has been marked as a duplicate of 24319 *** -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41164
[Bug rtl-optimization/24319] [4.3/4.4/4.5 regression] amd64 register spill error with -fschedule-insns
--- Comment #15 from ubizjak at gmail dot com 2009-08-27 17:33 --- *** Bug 41164 has been marked as a duplicate of this bug. *** -- ubizjak at gmail dot com changed: What|Removed |Added CC||lucier at math dot purdue ||dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24319
[Bug fortran/39667] I/O possibly unneccesary truncations
--- Comment #5 from jb at gcc dot gnu dot org 2009-08-27 17:41 --- Subject: Bug 39667 Author: jb Date: Thu Aug 27 17:40:55 2009 New Revision: 151144 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151144 Log: PR libfortran/39667 Fix testcases to not need fd_truncate. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/f2003_io_4.f03 trunk/gcc/testsuite/gfortran.dg/fmt_cache_1.f trunk/gcc/testsuite/gfortran.dg/fmt_exhaust.f90 trunk/gcc/testsuite/gfortran.dg/fmt_t_4.f90 trunk/gcc/testsuite/gfortran.dg/fseek.f90 trunk/gcc/testsuite/gfortran.dg/list_read_5.f90 trunk/gcc/testsuite/gfortran.dg/namelist_39.f90 trunk/gcc/testsuite/gfortran.dg/namelist_56.f90 trunk/gcc/testsuite/gfortran.dg/read_bad_advance.f90 trunk/gcc/testsuite/gfortran.dg/read_repeat.f90 trunk/gcc/testsuite/gfortran.dg/read_size_noadvance.f90 trunk/gcc/testsuite/gfortran.dg/read_x_past.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39667
[Bug testsuite/41166] [4.5 Regression] Syntax error: Unterminated quoted string
--- Comment #6 from rwild at gcc dot gnu dot org 2009-08-27 18:59 --- Subject: Bug 41166 Author: rwild Date: Thu Aug 27 18:59:32 2009 New Revision: 151145 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151145 Log: Let test_summary invoke, not parse config.status contents. contrib/* PR testsuite/41166 * test_summary: Invoke config.status, rather than trying to parse it. Adjust awk script. Modified: trunk/contrib/ChangeLog trunk/contrib/test_summary -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41166
[Bug middle-end/40965] [4.5 Regression][graphite] slow compilation
--- Comment #12 from spop at gcc dot gnu dot org 2009-08-27 19:13 --- Subject: Re: [4.5 Regression][graphite] slow compilation This fix also decreases the compile time of graphite in general. Â I will send a pointer to the automatic tester output that shows this on the SPEC benchmarks. Before data dep compile time fixes: http://gcc-graphite-test.googlegroups.com/attach/2944d6b8db76028b/cpu2006.compile.png?view=1part=4 http://gcc-graphite-test.googlegroups.com/attach/2944d6b8db76028b/cpu2006?view=1part=2 After: http://gcc-graphite-test.googlegroups.com/attach/e5e1c39697fdc3e6/cpu2006.compile.png?view=1part=3 http://gcc-graphite-test.googlegroups.com/attach/e5e1c39697fdc3e6/cpu2006?view=1part=2 Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40965
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #31 from mahatma at eu dot by 2009-08-27 19:17 --- Seamonkey still more unstable then with 4.3.3. With system libs, -O3 sse - ruuning only in safe-mode. All system rebuilt with 4.4.1 this patch. There are looks like seamonkey problem (and I will add -mno-sse into ebuild for 4.4), but 4.3.3 or -mno-sse (all for seamonkey only) solving problem (4.3.3 regression patch no result too). IMHO in some situation(s) stack still unaligned. If I will find some more precise - I will say... PS Also IMHO must be checked with -msseregparm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug testsuite/41166] contrib/test_summary should not depend upon config.status
--- Comment #7 from rwild at gcc dot gnu dot org 2009-08-27 19:04 --- Changing bug title to reflect the remaining issues; not a regression any more. -- rwild at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.5 Regression] Syntax |contrib/test_summary should |error: Unterminated quoted |not depend upon |string |config.status http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41166
[Bug fortran/40869] [F03] PPC assignment checking
--- Comment #1 from janus at gcc dot gnu dot org 2009-08-27 19:49 --- Subject: Bug 40869 Author: janus Date: Thu Aug 27 19:48:46 2009 New Revision: 151147 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151147 Log: 2009-08-27 Janus Weil ja...@gcc.gnu.org PR fortran/40869 * expr.c (gfc_check_pointer_assign): Enable interface check for pointer assignments involving procedure pointer components. * gfortran.h (gfc_compare_interfaces): Modified prototype. * interface.c (gfc_compare_interfaces): Add argument 'name2', to be used instead of s2-name. Don't rely on the proc_pointer attribute, but instead on the flags handed to this function. (check_interface1,compare_parameter): Add argument for gfc_compare_interfaces. * resolve.c (check_generic_tbp_ambiguity): Ditto. 2009-08-27 Janus Weil ja...@gcc.gnu.org PR fortran/40869 * gfortran.dg/proc_ptr_comp_20.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_20.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40869
[Bug c++/41135] Uninitialized variable usage warning broken
--- Comment #4 from bgamari at gmail dot com 2009-08-27 19:49 --- This was reported against the Ubuntu package as Launchpad bug #420129 (https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/420129) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41135
[Bug fortran/40869] [F03] PPC assignment checking
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-27 19:53 --- Fixed with r151147. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40869
[Bug debug/41065] DW_TAG_enumeration_type+DW_TAG_enumerator is sometimes missing
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-27 20:12:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41065
[Bug rtl-optimization/35404] ra-conflict does not handle subregs optimally
--- Comment #8 from aldot at gcc dot gnu dot org 2009-08-27 20:28 --- (In reply to comment #7) any regressions, if any exist at all, must be addressed by vlad's new register allocator. IRA is now on trunk, is this fixed on 4.4.x ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35404
[Bug rtl-optimization/40861] [4.4/4.5 Regression] ICE in simplify_subreg, at simplify-rtx.c:4981
--- Comment #5 from uros at gcc dot gnu dot org 2009-08-27 20:54 --- Subject: Bug 40861 Author: uros Date: Thu Aug 27 20:54:28 2009 New Revision: 151149 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151149 Log: PR rtl-optimization/40861 * simplify-rtx.c (simplify_subreg): Do not call simplify_gen_subreg to extract word from a multi-word subreg for negative byte positions. testsuite/ChangeLog: PR rtl-optimization/40861 * gcc.dg/pr40861.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr40861.c Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40861
[Bug fortran/41177] Wrong base-object checks for type-bound procedures
--- Comment #3 from janus at gcc dot gnu dot org 2009-08-27 20:56 --- (In reply to comment #1) Janus, how's that also related to PPCs? At first glance it seems we have the same problems for PPCs also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41177
[Bug middle-end/40106] Time increase for the Polyhedron test air.f90 due to bad optimization
--- Comment #17 from dominiq at lps dot ens dot fr 2009-08-27 21:59 --- Created an attachment (id=18439) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18439action=view) reduced test without any subroutine I have attached a reduced test without any subroutine. It requires the same input as air.f90, but do not expect meaningful results. As such I get: [ibook-dhum] lin/test% gfc -m64 -O2 -funsafe-math-optimizations air_db.f90 [ibook-dhum] lin/test% time a.out /dev/null 4.306u 0.015s 0:04.32 99.7% 0+0k 0+1io 0pf+0w If I comment line 94 WRITE (6,*) i , spx(i) , epx(i) , NPX(i) I get [ibook-dhum] lin/test% gfc -m64 -O2 -funsafe-math-optimizations air_db.f90 [ibook-dhum] lin/test% time a.out /dev/null 6.464u 0.020s 0:06.49 99.8% 0+0k 0+2io 0pf+0w Among the weirdness of this pr, if I comment also the line 502 WRITE (7,*) MXPx , MXPy I get [ibook-dhum] lin/test% gfc -m64 -O2 -funsafe-math-optimizations air_db.f90 [ibook-dhum] lin/test% time a.out /dev/null 4.273u 0.014s 0:04.29 99.7% 0+0k 0+0io 0pf+0w -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106
[Bug testsuite/39752] test-demangle.c failed to compile
--- Comment #2 from jason at gcc dot gnu dot org 2009-08-28 00:24 --- Fixed in rev 148526. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39752
[Bug middle-end/40106] Time increase for the Polyhedron test air.f90 due to bad optimization
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2009-08-28 01:09 --- Why don't you go back to the original test case and see which component of -funsafe-math-optimizations... -fno-signed-zeros -fno-trapping-math -fassociative-math -freciprocal-math is actually causing the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106
[Bug c++/41180] New: can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
Hi I'm not able to build gcc 4.4.1 on Snow Leopard Mac Pro ( gmp 4.3.1 and mpfr 2.4.1 were built without problem #gmp cd gmp-4.3.1 ./configure --prefix=/home/dmarkman/Development/GCC/macintel64/gmp-4.3.1/build make make install make check #mpfr cd ../mpfr-2.4.1 ./configure --prefix=/home/dmarkman/Development/GCC/macintel64/mpfr-2.4.1/build --with-gmp=/home/dmarkman/Development/GCC/macintel64/gmp-4.3.1/build make make install make check #gcc cd ../gcc-4.4.1 ./configure --prefix=/home/dmarkman/Development/GCC/macintel64/mpfr-2.4.1/build --with-gmp=/home/dmarkman/Development/GCC/macintel64/gmp-4.3.1/build make make compalins about incompatible library arch. gmp and mpfr were built as x86_64 libraries I verified it with file command so I just forced some flags to be x86_64: setenv LDFLAGS -arch x86_64 setenv CFLAGS -arch x86_64 setenv CXXFLAGS -arch x86_64 setenv CPPFLAGS -arch x86_64 make clean make distclean ./configure --prefix=/home/dmarkman/Development/GCC/macintel64/mpfr-2.4.1/build --with-gmp=/home/dmarkman/Development/GCC/macintel64/gmp-4.3.1/build make and after that I got another error: checking for i386-apple-darwin10.0.0-gcc... /Volumes/Macintosh_HD/Users/Shared/Development/GCC/gcc-4.4.1/host-i386-apple-darwin10.0.0/gcc/xgcc -B/Volumes/Macintosh_HD/Users/Shared/Development/GCC/gcc-4.4.1/host-i386-apple-darwin10.0.0/gcc/ -B/home/dmarkman/Development/GCC/macintel64/gcc-4.4.1/build/i386-apple-darwin10.0.0/bin/ -B/home/dmarkman/Development/GCC/macintel64/gcc-4.4.1/build/i386-apple-darwin10.0.0/lib/ -isystem /home/dmarkman/Development/GCC/macintel64/gcc-4.4.1/build/i386-apple-darwin10.0.0/include -isystem /home/dmarkman/Development/GCC/macintel64/gcc-4.4.1/build/i386-apple-darwin10.0.0/sys-include checking for suffix of object files... configure: error: in `/Volumes/Macintosh_HD/Users/Shared/Development/GCC/gcc-4.4.1/i386-apple-darwin10.0.0/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage1-target-libgcc] Error 1 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 -- Summary: can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6 Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dmarkman at mac dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug c++/41180] can not build gcc 4.4.1 on Snow Leopard Mac OS X 10.6
--- Comment #1 from dmarkman at mac dot com 2009-08-28 03:17 --- Created an attachment (id=18440) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18440action=view) config.log for failed build this is config.log for the failed build -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41180
[Bug c++/37920] ICE (segv) with typename typeof in local struct
--- Comment #5 from mbarrien at cs dot stanford dot edu 2009-08-28 05:12
---
I just ran into this bug too. Before I found this bug report, I did some more
investigation to characterize the bug a little more. I am including my version
of the reduced test case, with more commentary inline.
--
// Cause: Use of __typeof__ on a templated type (dependent upon template
arguments of outer function/class) as the type of an argument for any function
in a locally defined class crashes g++. Since this successfully typechecks, I
suspect that during symbol lookup in some IR generating phase, for arguments to
a function of a local class, if a __typeof__ is involved, g++ does not properly
lookup symbols in the outer function/class symbol table.
templatetypename ImplList struct VertexData;
templatetypename LM void init() {// Making non-templated function
eliminates ICE. (Also ICEs for non-templated member function in a templated
class.)
VertexDataLM* v0;// Making this non-template
eliminates ICE. Changing LM to int eliminates ICE.
typedef __typeof__(v0) v0_type_; // Using VertexDataLM instead
of __typeof__(v0) eliminates ICE. Using __decltype(v0) still causes ICE in GCC
4.3.4, but eliminates ICE in GCC 4.4
struct MeshConditionalInit { // Removing body of struct
eliminates ICE.
MeshConditionalInit(v0_type_ v0) { } // Removing argument eliminates
ICE. Using v0_type_ only in body and not as argument eliminates ICE.
}; // ICE still occurs when used as
function argument instead of constructor argument.
MeshConditionalInit bar138(v0);
}
int main(int argn, char ** argv) {
initint();
}
--
ICE occurs with no special compile flags in the following standard distribution
packages of GCC:
4.1.3, 4.2.4, and 4.3.3 on Ubuntu 9.04
4.0.1 and 4.2.1 on Mac OS X 10.5 (the versions with XCode)
4.4.0 on Mac OS X 10.5 (MacPorts build)
And because I got bored, here's a 140-character twitterable version of an even
smaller test case (inlines the typeof into the constructor's argument, removing
the typedef, which may not be legal, but definitely still causes an ICE in
GCC):
--
/*GCC Instacrash*/ templateclass T class C;templateclass U void f() {CU*
i;struct S{S(__typeof__(i) i){}}s(i);}int main(){fint();}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37920
[Bug middle-end/40106] Time increase for the Polyhedron test air.f90 due to bad optimization
--- Comment #19 from dominiq at lps dot ens dot fr 2009-08-28 05:39 --- Why don't you go back to the original test case and see which component of -funsafe-math-optimizations... -fno-signed-zeros -fno-trapping-math -fassociative-math -freciprocal-math is actually causing the problem. See http://gcc.gnu.org/ml/fortran/2009-08/msg00390.html : I have dug the problem a little bit more and found that the key option is -funsafe-math-optimizations. I tried to refine that, but as usual this option is not the sum of -fassociative-math -fno-signed-zeros -fno-trapping-math -freciprocal-math as said in the manual!-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40106
