[Bug fortran/37498] [4.4 Regression] Incorrect array value returned - 4.3 ABI Broken
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2008-09-23 06:26 --- I was doing some additional testing after the above patch and see that it breaks other things w.r.t 4.3 ABI. An example is namelist_14.f90 which fails with a 4.3 executable and 4.4 library. I am keeping this PR open while I sort this issue out further. 4.3 kept delim_status in unit_flags instead of in the st_parameter_dt of 4.4 Stay tuned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37498
[Bug fortran/36374] nested module inclusion fails
--- Comment #6 from pault at gcc dot gnu dot org 2008-09-23 06:27 --- Subject: Bug 36374 Author: pault Date: Tue Sep 23 06:25:39 2008 New Revision: 140578 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140578 Log: 2008-09-23 Paul Thomas [EMAIL PROTECTED] PR fortran/37274 PR fortran/36374 * module.c (check_for_ambiguous): New function to test loaded symbol for ambiguity with fixup symbol. (read_module): Call check_for_ambiguous. (write_symtree): Do not write the symtree for symbols coming from an interface body. PR fortran/36374 * resolve.c (count_specific_procs ): New function to count the number of specific procedures with the same name as the generic and emit appropriate errors for and actual argument reference. (resolve_assumed_size_actual): Add new argument no_formal_args. Correct logic around passing generic procedures as arguments. Call count_specific_procs from two locations. (resolve_function): Evaluate and pass no_formal_args. (resolve call): The same and clean up a bit by using csym more widely. PR fortran/36454 * symbol.c (gfc_add_access): Access can be updated if use associated and not private. 2008-09-23 Paul Thomas [EMAIL PROTECTED] PR fortran/37274 * gfortran.dg/used_types_22.f90: New test. * gfortran.dg/used_types_23.f90: New test. PR fortran/36374 * gfortran.dg/generic_17.f90: New test. * gfortran.dg/ambiguous_specific_2.f90: New test. * gfortran.dg/generic_actual_arg.f90: Add test for case that is not ambiguous. PR fortran/36454 * gfortran.dg/access_spec_3.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/access_spec_3.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/ambiguous_specific_2.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/generic_17.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/used_types_22.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/used_types_23.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/module.c branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/fortran/symbol.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/generic_actual_arg.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36374
[Bug fortran/36454] too cautionous alias checking with renamed variables/types from modules (Error: ACCESS specification already specified)
--- Comment #6 from pault at gcc dot gnu dot org 2008-09-23 06:27 --- Subject: Bug 36454 Author: pault Date: Tue Sep 23 06:25:39 2008 New Revision: 140578 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140578 Log: 2008-09-23 Paul Thomas [EMAIL PROTECTED] PR fortran/37274 PR fortran/36374 * module.c (check_for_ambiguous): New function to test loaded symbol for ambiguity with fixup symbol. (read_module): Call check_for_ambiguous. (write_symtree): Do not write the symtree for symbols coming from an interface body. PR fortran/36374 * resolve.c (count_specific_procs ): New function to count the number of specific procedures with the same name as the generic and emit appropriate errors for and actual argument reference. (resolve_assumed_size_actual): Add new argument no_formal_args. Correct logic around passing generic procedures as arguments. Call count_specific_procs from two locations. (resolve_function): Evaluate and pass no_formal_args. (resolve call): The same and clean up a bit by using csym more widely. PR fortran/36454 * symbol.c (gfc_add_access): Access can be updated if use associated and not private. 2008-09-23 Paul Thomas [EMAIL PROTECTED] PR fortran/37274 * gfortran.dg/used_types_22.f90: New test. * gfortran.dg/used_types_23.f90: New test. PR fortran/36374 * gfortran.dg/generic_17.f90: New test. * gfortran.dg/ambiguous_specific_2.f90: New test. * gfortran.dg/generic_actual_arg.f90: Add test for case that is not ambiguous. PR fortran/36454 * gfortran.dg/access_spec_3.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/access_spec_3.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/ambiguous_specific_2.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/generic_17.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/used_types_22.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/used_types_23.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/module.c branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/fortran/symbol.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/generic_actual_arg.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36454
[Bug fortran/37274] [Regression on 4.3?] error: type name is ambiguous.
--- Comment #20 from pault at gcc dot gnu dot org 2008-09-23 06:27 --- Subject: Bug 37274 Author: pault Date: Tue Sep 23 06:25:39 2008 New Revision: 140578 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140578 Log: 2008-09-23 Paul Thomas [EMAIL PROTECTED] PR fortran/37274 PR fortran/36374 * module.c (check_for_ambiguous): New function to test loaded symbol for ambiguity with fixup symbol. (read_module): Call check_for_ambiguous. (write_symtree): Do not write the symtree for symbols coming from an interface body. PR fortran/36374 * resolve.c (count_specific_procs ): New function to count the number of specific procedures with the same name as the generic and emit appropriate errors for and actual argument reference. (resolve_assumed_size_actual): Add new argument no_formal_args. Correct logic around passing generic procedures as arguments. Call count_specific_procs from two locations. (resolve_function): Evaluate and pass no_formal_args. (resolve call): The same and clean up a bit by using csym more widely. PR fortran/36454 * symbol.c (gfc_add_access): Access can be updated if use associated and not private. 2008-09-23 Paul Thomas [EMAIL PROTECTED] PR fortran/37274 * gfortran.dg/used_types_22.f90: New test. * gfortran.dg/used_types_23.f90: New test. PR fortran/36374 * gfortran.dg/generic_17.f90: New test. * gfortran.dg/ambiguous_specific_2.f90: New test. * gfortran.dg/generic_actual_arg.f90: Add test for case that is not ambiguous. PR fortran/36454 * gfortran.dg/access_spec_3.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/access_spec_3.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/ambiguous_specific_2.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/generic_17.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/used_types_22.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/used_types_23.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/module.c branches/gcc-4_3-branch/gcc/fortran/resolve.c branches/gcc-4_3-branch/gcc/fortran/symbol.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/generic_actual_arg.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37274
[Bug fortran/37274] [Regression on 4.3?] error: type name is ambiguous.
--- Comment #21 from pault at gcc dot gnu dot org 2008-09-23 06:28 --- Fixed on trunk and 4.3. Thanks for the report Paul PS The original problem was not present in 4.3 but the reduced version was. -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37274
[Bug fortran/36454] too cautionous alias checking with renamed variables/types from modules (Error: ACCESS specification already specified)
--- Comment #7 from pault at gcc dot gnu dot org 2008-09-23 06:28 --- Fixed on trunk and 4.3. Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36454
[Bug fortran/36374] nested module inclusion fails
--- Comment #7 from pault at gcc dot gnu dot org 2008-09-23 06:29 --- Fixed on trunk and 4.3. Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36374
[Bug fortran/37580] [4.3/4.4 Regression] Accepts pointer(:) = target without lower bound
--- Comment #5 from burnus at gcc dot gnu dot org 2008-09-23 08:01 --- Subject: Bug 37580 Author: burnus Date: Tue Sep 23 08:00:01 2008 New Revision: 140580 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140580 Log: 2008-09-22 Tobias Burnus [EMAIL PROTECTED] PR fortran/37580 * expr.c (gfc_check_pointer_assign): Add checks for pointer remapping. 2008-09-22 Tobias Burnus [EMAIL PROTECTED] PR fortran/37580 * gfortran.dg/pointer_assign_5.f90: New test. * gfortran.dg/pointer_assign_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pointer_assign_5.f90 trunk/gcc/testsuite/gfortran.dg/pointer_assign_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37580
[Bug bootstrap/37612] libgcc/configure (as script)fail with line 77 exec : : not found.
--- Comment #2 from nospamname at web dot de 2008-09-23 08:19 --- thanks when i copy as ln for quick test to gcc dir then this error not come. I remove that path before, because i fear clashes between the x86 cygwin compilers and old 3.4 68k compilers and binutils. maybe in the as script can add text on fail, as File not found ?.this make clear that problem is not in gcc configure when i add the path to my 68k compiler /usr/local/amiga/bin in search path (bin/lib/include) files and do the whole compile again does this work and is safe to use X86 cygwin and 68k compilers together in path ? I think i must then add the path to my 68k compilers after the path to the X86 compilers right ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37612
[Bug ada/37618] New: parameter used for dispatching gives warning: formal parameter X is not referenced
A parameter of a type without actual data components, that is only used for dispatching, gives: warning: formal parameter X is not referenced But the type is a null record, so there is nothing that could be referenced. And the parameter is actually used to select which function to call. Sample code will be attached. -- Summary: parameter used for dispatching gives warning: formal parameter X is not referenced Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: esigra at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37618
[Bug ada/37618] parameter used for dispatching gives warning: formal parameter X is not referenced
--- Comment #1 from esigra at gmail dot com 2008-09-23 09:38 --- Created an attachment (id=16383) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16383action=view) Makefile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37618
[Bug ada/37619] New: overriding Finalize gives: warning: declaration of Finalize hides one at line N
The procedure Finalize is supposed to be overridden to get a constructor for a type, but doing so gives a warning, eventhough the code explicitly states that the new Finalize should override the old one. Sample code attached. -- Summary: overriding Finalize gives: warning: declaration of Finalize hides one at line N Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: esigra at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37619
[Bug ada/37619] overriding Finalize gives: warning: declaration of Finalize hides one at line N
--- Comment #1 from esigra at gmail dot com 2008-09-23 09:51 --- Created an attachment (id=16386) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16386action=view) Makefile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37619
[Bug ada/37619] overriding Finalize gives: warning: declaration of Finalize hides one at line N
--- Comment #2 from esigra at gmail dot com 2008-09-23 09:51 --- Created an attachment (id=16387) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16387action=view) specification -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37619
[Bug ada/37619] overriding Finalize gives: warning: declaration of Finalize hides one at line N
--- Comment #3 from esigra at gmail dot com 2008-09-23 09:52 --- Created an attachment (id=16388) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16388action=view) implementation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37619
[Bug ada/37618] parameter used for dispatching gives warning: formal parameter X is not referenced
--- Comment #2 from esigra at gmail dot com 2008-09-23 09:39 --- Created an attachment (id=16384) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16384action=view) specification -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37618
[Bug ada/37618] parameter used for dispatching gives warning: formal parameter X is not referenced
--- Comment #3 from esigra at gmail dot com 2008-09-23 09:39 --- Created an attachment (id=16385) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16385action=view) implementation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37618
[Bug fortran/37583] ICE insert_bbt(): Duplicate key for self-calling ENTRY subprogram
--- Comment #8 from pault at gcc dot gnu dot org 2008-09-23 10:10 --- (In reply to comment #6) Thanks to you both - I did not look subsequently at this PR. I hit the problem with ENTRY_1.F90, of course and my solution was one and the same. Many thanks for the coup de main and sorry that I missed it. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37583
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #41 from pluto at agmk dot net 2008-09-23 10:12 --- and the lastest patch causes internal error in cc1plus in my codebase: $ /local/devel/toolchain43/x86_64-gnu-linux.host64.diag/bin/x86_64-gnu-linux-g++ smsSimClock.ii -c -std=gnu++0x Internal compiler error: Error reporting routines re-entered. Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #42 from pluto at agmk dot net 2008-09-23 10:13 --- Created an attachment (id=16389) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16389action=view) internal-error-testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug ada/37620] warning: variable X is not referenced eventhough it is referenced by (implicit) procedure calls
--- Comment #1 from esigra at gmail dot com 2008-09-23 10:26 --- Created an attachment (id=16390) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16390action=view) Makefile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37620
[Bug ada/37620] warning: variable X is not referenced eventhough it is referenced by (implicit) procedure calls
--- Comment #2 from esigra at gmail dot com 2008-09-23 10:27 --- Created an attachment (id=16391) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16391action=view) implementation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37620
[Bug ada/37620] New: warning: variable X is not referenced eventhough it is referenced by (implicit) procedure calls
Even though a variable is referenced by (implicit) procedure calls (such as Initialize and Finalize), GCC gives: warning: variable X is not referenced This happens especially when using the RAII design pattern. The warning should not be shown when the variable is referenced by a procedure call, even if it is implicit. Sample code attached. -- Summary: warning: variable X is not referenced eventhough it is referenced by (implicit) procedure calls Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: esigra at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37620
[Bug ada/37620] warning: variable X is not referenced eventhough it is referenced by (implicit) procedure calls
--- Comment #3 from esigra at gmail dot com 2008-09-23 10:32 --- Created an attachment (id=16392) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16392action=view) Makefile -- esigra at gmail dot com changed: What|Removed |Added Attachment #16390|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37620
[Bug ada/37620] warning: variable X is not referenced eventhough it is referenced by (implicit) procedure calls
--- Comment #4 from sam at gcc dot gnu dot org 2008-09-23 11:32 --- I don't agree with your reasoning: X is not referenced. The fact that it has a constructor should not change anything. For example, access types are initialized to Null as well, so you could count that as a reference. You can suppress the warning by using pragma Unreferenced (X); -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37620
[Bug bootstrap/37612] libgcc/configure (as script)fail with line 77 exec : : not found.
--- Comment #3 from brian at dessent dot net 2008-09-23 11:43 --- Subject: Re: libgcc/configure (as script)fail with line 77 exec : : not found. Your cross-assembler and linker should be named $target-as and $target-ld so they can't clash with the host tools, and this is what the configure script will look for. This is the default when building a cross-binutils so unless you go out of your way to break it everything should be fine -- just make sure to configure both cross-binutils and cross-gcc with the same target so that the names match. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37612
[Bug inline-asm/37621] New: Missing documentation for x86 inline assembler modifiers
I came across the following modifiers for inline assembler: asm (rorw $8, %w0 : =q (y) : 0 (x)); asm (xchg %b0, %h0 : =q (y) : 0 (x)); They work very well. No bug in the compiler itself, but I haven't found anything about them in the online documentation. Note: The %w0, %b0 and %h0 modifiers allows us to access thesub-registers of a 32 bit register. E.g. if %0 is EAX, %w0 becomes AX, %b0 becomes AL and %h0 becomes AH. -- Summary: Missing documentation for x86 inline assembler modifiers Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: inline-asm AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: n dot pipenbrinck at cubic dot org GCC host triplet: x86 GCC target triplet: x86 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37621
[Bug fortran/36592] F2003: Procedure pointer in COMMON
--- Comment #3 from janus at gcc dot gnu dot org 2008-09-23 12:44 ---
(In reply to comment #2)
How about the following patch?
Looks very good, and does what it should. Just one thing: We will also have to
check for attr.in_common, so that normal procptrs don't get messed up.
Otherwise it's fine. The complete patch then looks like this:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 140547)
+++ gcc/fortran/symbol.c(working copy)
@@ -1133,13 +1133,7 @@ gfc_add_in_common (symbol_attribute *att
/* Duplicate attribute already checked for. */
attr-in_common = 1;
- if (check_conflict (attr, name, where) == FAILURE)
-return FAILURE;
-
- if (attr-flavor == FL_VARIABLE)
-return SUCCESS;
-
- return gfc_add_flavor (attr, FL_VARIABLE, name, where);
+ return check_conflict (attr, name, where);
}
Index: gcc/fortran/trans-types.c
===
--- gcc/fortran/trans-types.c (revision 140547)
+++ gcc/fortran/trans-types.c (working copy)
@@ -1627,6 +1627,16 @@ gfc_sym_type (gfc_symbol * sym)
tree type;
int byref;
+ /* Procedure Pointers inside COMMON blocks. */
+ if (sym-attr.proc_pointer sym-attr.in_common)
+{
+ /* Unset proc_pointer as gfc_get_function_type calls gfc_sym_type. */
+ sym-attr.proc_pointer = 0;
+ type = build_pointer_type (gfc_get_function_type (sym));
+ sym-attr.proc_pointer = 1;
+ return type;
+}
+
if (sym-attr.flavor == FL_PROCEDURE !sym-attr.function)
return void_type_node;
This correctly compiles and runs the following extended test case:
subroutine one()
implicit none
common /com/ p1,p2,a,b
procedure(real), pointer :: p1,p2
integer :: a,b
print *,a,b,p1(0.0),p2(0.0)
end subroutine one
program main
implicit none
integer :: x,y
intrinsic sin,cos
procedure(real), pointer :: func1
external func2
pointer func2
common /com/ func1,func2,x,y
x = 5
y = -9
func1 = cos
func2 = sin
call one()
end program main
I'm checking for regressions right now. Is there anything else we need to take
care of? (If I read the standard correctly, procptrs are forbidden in
EQUIVALENCE statements, right?)
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2008-09-22 20:22:49 |2008-09-23 12:44:14
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36592
[Bug debug/37410] DW_TAG_imported_module is not in its DW_TAG_lexical_block
--- Comment #2 from dodji at gcc dot gnu dot org 2008-09-23 13:04 --- Created an attachment (id=16393) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16393action=view) first fix candidate This patch seems to fix the problem for me and passes regtests on trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37410
[Bug debug/37410] DW_TAG_imported_module is not in its DW_TAG_lexical_block
--- Comment #3 from dodji at gcc dot gnu dot org 2008-09-23 13:08 --- (From update of attachment 16393) The idea of the patch is to add an IMPORTED_DECL node to the lexical BLOCK enclosing the using directive.This is done at gimplification time. Then the patch modifies dwarf2out.c to recognize the new IMPORTED_DECL node and generate the DW_TAG_imported_module dwarf tag accordingly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37410
[Bug testsuite/37622] New: gcc.dg: failure reported for direct2s.c
Clean build from a source tree that was the result of svn switching to the 4.3.2 release tag (was previously a 4.3.0 release I think). make check reports a handful of errors; I'm logging each separately once I determine the likely cause. the gcc.dg/cpp/direct2s.c test fails with test for excess errors. The message is warning: current file is older than direct2.c. I suspect that it was an error to duplicate the #pragma GCC dependency direct2.c line from direct2.c instead of changing it to #pragma GCC dependency direct2s.c Of course this problem would only be triggered if direct2s.c is older than direct2.c, which is unlikely to happen except as the result of a svn up/switch. -- Summary: gcc.dg: failure reported for direct2s.c Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tim dot vanholder at anubex dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37622
[Bug testsuite/37623] New: builtin-math-4 tests fail
Clean build from a source tree that was the result of svn switching to the 4.3.2 release tag (was previously a 4.3.0 release I think). make check reports a handful of errors; I'm logging each separately once I determine the likely cause. The builtin-math-4.c test (8 flavours) from gcc.dg fails. Lots of linker errors for link_error in the log (which looks like the expected failure type for the testcase). Notable is all flavours except the -O0 one have linker errors other than the intentional link_error ones. In particular, the gamma_r, gammal_r, gammaf_r end up being undefined, so it looks like some not-always-builtin math routines are also included in the test. I'll attach the error list for the test that uses -g, as there the line numbers of the link errors are included. -- Summary: builtin-math-4 tests fail Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tim dot vanholder at anubex dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37623
[Bug testsuite/37623] builtin-math-4 tests fail
--- Comment #1 from tim dot vanholder at anubex dot com 2008-09-23 13:45 --- Created an attachment (id=16394) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16394action=view) Test results for builtin-math-4.c -O3 -g -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37623
[Bug libgcj/8995] race cases in interpreter
--- Comment #7 from aph at gcc dot gnu dot org 2008-09-23 13:52 --- Subject: Bug 8995 Author: aph Date: Tue Sep 23 13:51:58 2008 New Revision: 140593 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140593 Log: 2008-09-17 Andrew Haley [EMAIL PROTECTED] PR libgcj/8995: * defineclass.cc (_Jv_ClassReader::handleCodeAttribute): Initialize thread_count. * include/java-interp.h (_Jv_InterpMethod::thread_count): New field. (_Jv_InterpMethod::rewrite_insn_mutex): New mutex. (_Jv_InterpFrame:: _Jv_InterpFrame): Pass frame_type. * interpret.cc (ThreadCountAdjuster): New class. (_Jv_InterpMethod::thread_count): New field. (_Jv_InitInterpreter): Initialize rewrite_insn_mutex. Increment and decrement thread_count field in methods. * interpret-run.cc (REWRITE_INSN): Check thread_count = 1. (REWRITE_INSN): Likewise. Declare a ThreadCountAdjuster. * java/lang/reflect/natVMProxy.cc (run_proxy): Initialize frame type as frame_proxy. Modified: trunk/libjava/ChangeLog trunk/libjava/defineclass.cc trunk/libjava/include/java-interp.h trunk/libjava/interpret-run.cc trunk/libjava/interpret.cc trunk/libjava/java/lang/reflect/natVMProxy.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8995
[Bug fortran/37588] GENERIC type-bound procedure is not resolved
--- Comment #5 from domob at gcc dot gnu dot org 2008-09-23 14:28 --- Subject: Bug 37588 Author: domob Date: Tue Sep 23 14:26:47 2008 New Revision: 140594 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140594 Log: 2008-09-23 Daniel Kraft [EMAIL PROTECTED] PR fortran/37588 * gfortran.h (gfc_compare_actual_formal): Removed, made private. (gfc_arglist_matches_symbol): New method. * interface.c (compare_actual_formal): Made static. (gfc_procedure_use): Use new name of compare_actual_formal. (gfc_arglist_matches_symbol): New method. (gfc_search_interface): Moved code partially to new gfc_arglist_matches_symbol. * resolve.c (resolve_typebound_generic_call): Resolve actual arglist before checking against formal and use new gfc_arglist_matches_symbol for checking. (resolve_compcall): Set type-spec of generated expression. 2008-09-23 Daniel Kraft [EMAIL PROTECTED] PR fortran/37588 * gfortran.dg/typebound_generic_4.f03: New test. * gfortran.dg/typebound_generic_5.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/typebound_generic_4.f03 trunk/gcc/testsuite/gfortran.dg/typebound_generic_5.f03 Modified: trunk/gcc/fortran/ChangeLog 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=37588
[Bug fortran/37588] GENERIC type-bound procedure is not resolved
--- Comment #6 from domob at gcc dot gnu dot org 2008-09-23 14:29 --- Fixed on trunk. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37588
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #43 from b0ntrict0r at yandex dot ru 2008-09-23 14:31 --- (In reply to comment #42) Created an attachment (id=16389) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16389action=view) [edit] internal-error-testcase Hm... I can reproduce it with gcc 4.3.2 and cannot reproduce with 4.3.1: original and patches gcc 4.3.1 works correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug libstdc++/37391] examples not accessible online (non existing URLs)
--- Comment #5 from bkoz at gcc dot gnu dot org 2008-09-23 16:08 --- Subject: Bug 37391 Author: bkoz Date: Tue Sep 23 16:06:43 2008 New Revision: 140600 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140600 Log: 2008-09-23 Benjamin Kosnik [EMAIL PROTECTED] PR libstdc++/37391 continued. * doc/html/ext/pb_ds/assoc_examples.html: Don't use base tag, specify full path for source file links. * doc/html/ext/pb_ds/pq_examples.html: Same. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/html/ext/pb_ds/assoc_examples.html trunk/libstdc++-v3/doc/html/ext/pb_ds/pq_examples.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37391
[Bug target/37624] New: [4.4 Regression]: 22_locale/num_get/get/char/10.cc
With revision 140565 this test passed. From revision 140575 and on, this test has failed as follows: Running /tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp ... FAIL: 22_locale/num_get/get/char/10.cc execution test With the message in the logfile being: assertion err == ios_base::failbit failed: file /tmp/hpautotest-gcc1/gcc/libstdc++-v3/testsuite/22_locale/num_get/get/char/10.cc, line 63, function: void test01()^M program stopped with signal 6.^M Oddly enough, I don't see this failure for other targets at gcc-testresults@ so perhaps it's a target bug. Of course, it could still be a non-target bug like an uninitialized variable. I'm labelling it as a target bug pending further investigation. Anyway, author of patches in suspect revision range CC:ed. -- Summary: [4.4 Regression]: 22_locale/num_get/get/char/10.cc Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: cris-axis-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37624
[Bug target/37624] [4.4 Regression]: 22_locale/num_get/get/char/10.cc
--- Comment #1 from paolo dot carlini at oracle dot com 2008-09-23 16:12 --- I'm certainly willing to help but please provide more info: e.g., what is the value of err? Which is the path followed by cris-axis-elf in __convert_to_v(const char* __s, long double __v, ...)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37624
[Bug other/37625] New: 32-bit bootstrap failure on darwin9
I configured gcc with env CC=/usr/bin/gcc-4.0 ../gcc-4.3.2/configure --enable-languages=c --enable-checking=release --build=powerpc-apple-darwin9.5.0 --host=powerpc-apple-darwin9.5.0 --target=powerpc-apple-darwin9.5.0 --with-gmp-include=/sw/include/ --with-gmp-lib=/sw/lib/ --with-mpfr-include=/sw/include/ --with-mpfr-lib=/sw/lib --prefix=/pkgs/gcc-4.3.2-32 and bootstrapped with make -j 4 bootstrap BOOT_LDFLAGS='-Wl,-search_paths_first' and bootstrap failed with [descartes:~/programs/gcc-4.3.2-objdir/gcc] lucier% /usr/bin/gcc-4.0 -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o c-pch.o c-parser.o darwin-c.o rs6000-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o main.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ./../intl/libintl.a -liconv ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/sw/lib/ -L/sw/lib -lmpfr -lgmp -v Using built-in specs. Target: powerpc-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5488~2/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --program-prefix= --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5488) /usr/libexec/gcc/powerpc-apple-darwin9/4.0.1/collect2 -dynamic -arch ppc -macosx_version_min 10.5.5 -weak_reference_mismatches non-weak -o cc1-dummy -lcrt1.10.5.o -L/sw/lib/ -L/sw/lib -L/usr/lib/powerpc-apple-darwin9/4.0.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.0.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.0.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.0.1/../../../powerpc-apple-darwin9/4.0.1 -L/usr/lib/gcc/powerpc-apple-darwin9/4.0.1/../../.. c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o c-pch.o c-parser.o darwin-c.o rs6000-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o main.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ./../intl/libintl.a -liconv ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lmpfr -lgmp -lgcc_s.10.5 -lgcc -lSystemStubs -lSystem Undefined symbols: _iconv_close, referenced from: __cpp_destroy_iconv in libcpp.a(charset.o) __cpp_destroy_iconv in libcpp.a(charset.o) __cpp_convert_input in libcpp.a(charset.o) __nl_free_domain_conv in libintl.a(loadmsgcat.o) _iconv, referenced from: _convert_using_iconv in libcpp.a(charset.o) _convert_using_iconv in libcpp.a(charset.o) _convert_using_iconv in libcpp.a(charset.o) _convert_using_iconv in libcpp.a(charset.o) __nl_find_msg in libintl.a(dcigettext.o) _iconv_open, referenced from: _init_iconv_desc in libcpp.a(charset.o) __nl_init_domain_conv in libintl.a(loadmsgcat.o) __nl_init_domain_conv in libintl.a(loadmsgcat.o) ld: symbol(s) not found collect2: ld returned 1 exit status I built a 64-bit version of gcc-4.3.2 just fine with the command env CC='gcc -mcpu=970 -m64' ../gcc-4.3.2/configure --enable-checking=release --build=powerpc64-apple-darwin9.5.0 --host=powerpc64-apple-darwin9.5.0 --target=powerpc64-apple-darwin9.5.0 --with-gmp-include=/sw/include/ --with-gmp-lib=/sw/lib/ppc64 --with-mpfr-include=/sw/include/ --with-mpfr-lib=/sw/lib/ppc64 --prefix=/pkgs/gcc-4.3.2-64; make -j 4 bootstrap BOOT_LDFLAGS='-Wl,-search_paths_first' My environment: [descartes:~/programs/gcc-4.3.2-objdir/gcc] lucier% printenv TERM=xterm SHELL=/bin/tcsh TMPDIR=/var/folders/Xc/Xcp-rbVFEAqxxyTyi4mfzTI/-Tmp-/ Apple_PubSub_Socket_Render=/tmp/launch-0U0x5p/Render USER=lucier COMMAND_MODE=unix2003 SSH_AUTH_SOCK=/tmp/launch-HtteCk/Listeners __CF_USER_TEXT_ENCODING=0x1F5:0:0 PATH=/usr/local/Gambit-C/current/bin:/pkgs/gcc-4.3.2-64/bin:/usr/local/texlive/2008/bin/universal-darwin/:/sw/bin:/sw/sbin:/usr/local/Gambit-C/current/bin:/pkgs/gcc-4.3.2/bin:/usr/local/texlive/2008/bin/universal-darwin/:/usr/local/Gambit-C/current/bin:/usr/local/texlive/2008/bin/universal-darwin/:/usr/local/Gambit-C/current/bin:/usr/local/texlive/2007/bin/powerpc-darwin:/pkgs/gcc-4.2.3-64/bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin:/usr/X11R6/bin PWD=/Users/lucier/programs/gcc-4.3.2-objdir/gcc SHLVL=2 HOME=/Users/lucier LOGNAME=lucier DISPLAY=/tmp/launch-kPweHq/:0 SECURITYSESSIONID=605770 _=/usr/X11/bin/xterm
[Bug target/37624] [4.4 Regression]: 22_locale/num_get/get/char/10.cc
--- Comment #2 from paolo dot carlini at oracle dot com 2008-09-23 16:24 --- Ok, I think I know what's going wrong: please confirm that your target is using sscanf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37624
[Bug target/37624] [4.4 Regression]: 22_locale/num_get/get/char/10.cc
--- Comment #3 from paolo dot carlini at oracle dot com 2008-09-23 16:29 --- Assuming the weak check on sscanf return value is the issue, please test the attached patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37624
[Bug target/37624] [4.4 Regression]: 22_locale/num_get/get/char/10.cc
--- Comment #4 from paolo dot carlini at oracle dot com 2008-09-23 16:30 --- Created an attachment (id=16395) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16395action=view) Draft -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37624
[Bug target/37624] [4.4 Regression]: 22_locale/num_get/get/char/10.cc
--- Comment #5 from paolo dot carlini at oracle dot com 2008-09-23 16:36 --- Never mind, I know what's going wrong but the patch is not ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37624
[Bug target/37624] [4.4 Regression]: 22_locale/num_get/get/char/10.cc
--- Comment #6 from paolo dot carlini at oracle dot com 2008-09-23 16:45 --- Unfortunately, I think we have to xfail the test for targets not having available strtold and falling back to sscanf for long double parsing. Note that DR 23 mandates, for a reason, a behaviour equivalent to strtold, *not* sscanf, because the latter is weaker as regards error checking, essentially. On many targets, 6e is successfully parsed by sscanf as 6, whereas with strtold we can tell that not all the input is consumed and issue an error from the C++ library. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-23 16:45:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37624
[Bug libstdc++/37624] [4.4 Regression]: 22_locale/num_get/get/char/10.cc
--- Comment #7 from paolo at gcc dot gnu dot org 2008-09-23 17:13 --- Subject: Bug 37624 Author: paolo Date: Tue Sep 23 17:12:26 2008 New Revision: 140602 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140602 Log: 2008-09-23 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/37624 * testsuite/22_locale/num_get/get/char/10.cc: Skip long double case when strtold is not available. * testsuite/22_locale/num_get/get/wchar_t/10.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/22_locale/num_get/get/char/10.cc trunk/libstdc++-v3/testsuite/22_locale/num_get/get/wchar_t/10.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37624
[Bug libstdc++/37624] [4.4 Regression]: 22_locale/num_get/get/char/10.cc
--- Comment #8 from paolo dot carlini at oracle dot com 2008-09-23 17:15 --- . -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37624
[Bug libstdc++/37624] [4.4 Regression]: 22_locale/num_get/get/char/10.cc
--- Comment #9 from hp at gcc dot gnu dot org 2008-09-23 17:20 --- (In reply to comment #2) Ok, I think I know what's going wrong: please confirm that your target is using sscanf. You're too fast for me! :) Being a newlib cross target, it doesn't use strtold; newlib has no generic strtold. See the newlib stuff in the else-clause of the if $GLIBCXX_IS_NATIVE; then in configure.ac. (There's a strtod in newlib, and long double equals double for this and many targets. Not an excuse for not having a C99 standard-named function though.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37624
[Bug other/37625] 32-bit bootstrap failure on darwin9
--- Comment #1 from lucier at math dot purdue dot edu 2008-09-23 17:35 --- Forget it, the problem seems to be fixed by configuring with env CC=/usr/bin/gcc-4.0 ../gcc-4.3.2/configure --with-libiconv-prefix=/sw/ --enable-languages=c --enable-checking=release --build=powerpc-apple-darwin9.5.0 --host=powerpc-apple-darwin9.5.0 --target=powerpc-apple-darwin9.5.0 --with-gmp-include=/sw/include/ --with-gmp-lib=/sw/lib/ --with-mpfr-include=/sw/include/ --with-mpfr-lib=/sw/lib --prefix=/pkgs/gcc-4.3.2-32 i.e., by adding --with-libiconv-prefix=/sw/, the fink directory. I don't know why the 64-bit configure and build worked without that declaration. -- lucier at math dot purdue dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37625
[Bug libgcj/18266] GCJ: Using references drops finalizers causing all apps to eventually crash ( SIGSEGV in GC_register_finalizer_inner () )
--- Comment #18 from daney at gcc dot gnu dot org 2008-09-23 17:40 --- Created an attachment (id=16396) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16396action=view) Possible work-around This is a patch against 3.4.3 that we are seriously considering using internally. The theory is: With code compiled from valid java source, it is impossible to be GCable while holding a lock, so adding a finalizer is redundant. It is still not clear to me if the number of heavy_locks could grow without bound while using the patch. We are analyzing this now... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266
[Bug fortran/37626] New: Internal compiler error triggered by gfortran PACK intrinsic
The sample code below produces the following internal compiler error: unique_A.f90: In function 'unique_a': unique_A.f90:42: internal compiler error: Segmentation fault The error seems to be associated with use of the PACK() intrinsic. --CUT HERE-- function unique_A (x, sorted) result (x_unique) character(*), dimension(:), intent(in) :: x logical, intent(in), optional:: sorted character(LEN(x)), dimension(:), allocatable :: x_unique logical :: sorted_ character(LEN(x)), dimension(SIZE(x)):: x_sorted integer :: n_x logical, dimension(SIZE(x)) :: mask integer, external:: b3ss_index ! Set up sorted_ if(PRESENT(sorted)) then sorted_ = sorted else sorted_ = .FALSE. endif ! If necessary, sort x if(sorted_) then x_sorted = x else x_sorted = x(b3ss_index(x)) endif ! Set up the unique array n_x = SIZE(x) mask = (/.TRUE.,x_sorted(2:n_x) /= x_sorted(1:n_x-1)/) allocate(x_unique(COUNT(mask))) x_unique = PACK(x_sorted, MASK=mask) ! Finish return end function unique_A -- Summary: Internal compiler error triggered by gfortran PACK intrinsic Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: townsend at astro dot wisc dot edu GCC build triplet: x86_64-gentoo-linux GCC host triplet: x86_64-gentoo-linux GCC target triplet: x86_64-gentoo-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37626
[Bug bootstrap/37627] New: In function `fold_builtin_1': undefined reference to `mpfr_j0'
I just finished compiling mpfr-2.3.2 and was moving on to compile gcc-4.3.2, and i'm consistently getting the attached build error which ends with the snippet below. The error would suggest that, for example, the symbol / function mpfr_j0 is not defined in libmpfr, although it is clearly defined globally both in the static and the shared libraries. Where does this bug belong? I'm only submitting it here because it prevents me from building gcc, but I will gladly submit it to the mpfr people if it's their issue. Cheers, Chris PS: I will submit the attachment after the bug is filed. snip libbackend.a(builtins.o): In function `fold_builtin_1': /home/cfriedt/gcc/gcc-4.3.2/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/builtins.c:9973: undefined reference to `mpfr_j0' /home/cfriedt/gcc/gcc-4.3.2/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/builtins.c:9979: undefined reference to `mpfr_j1' /home/cfriedt/gcc/gcc-4.3.2/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/builtins.c:9985: undefined reference to `mpfr_y0' /home/cfriedt/gcc/gcc-4.3.2/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/builtins.c:9991: undefined reference to `mpfr_y1' libbackend.a(builtins.o): In function `fold_builtin_2': /home/cfriedt/gcc/gcc-4.3.2/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/builtins.c:10120: undefined reference to `mpfr_jn' /home/cfriedt/gcc/gcc-4.3.2/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/builtins.c:10126: undefined reference to `mpfr_yn' /home/cfriedt/gcc/gcc-4.3.2/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/builtins.c:10134: undefined reference to `mpfr_remainder' libbackend.a(builtins.o): In function `do_mpfr_remquo': /home/cfriedt/gcc/gcc-4.3.2/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/builtins.c:12957: undefined reference to `mpfr_remquo' libbackend.a(builtins.o): In function `do_mpfr_lgamma_r': /home/cfriedt/gcc/gcc-4.3.2/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/builtins.c:13035: undefined reference to `mpfr_lgamma' collect2: ld returned 1 exit status /snip -- Summary: In function `fold_builtin_1': undefined reference to `mpfr_j0' Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cfriedt at visible-assets dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37627
[Bug testsuite/37628] New: gcc.c-torture/execute/pr35456.c is not generic
It assumes the existence of signed 0.0 which is not available across all FP implementations. Specifically, this test fails on VAX since VAX FP has no concept of -0.0. In fact, -0.0 would cause a reserved operand fault. -- Summary: gcc.c-torture/execute/pr35456.c is not generic Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matt at 3am-software dot com GCC build triplet: x86-64--netbsd GCC host triplet: x86_64--netbsd GCC target triplet: vax--netbsdelf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37628
[Bug bootstrap/37627] In function `fold_builtin_1': undefined reference to `mpfr_j0'
--- Comment #1 from cfriedt at visible-assets dot com 2008-09-23 18:31 --- Created an attachment (id=16397) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16397action=view) output of 'gcc -v -save-temps' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37627
[Bug testsuite/37623] builtin-math-4 tests fail
--- Comment #2 from jakub at gcc dot gnu dot org 2008-09-23 18:33 --- That probably means you have too old mpfr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37623
[Bug c++/37146] [4.4 Regression] Invalid types with COND_EXPR
--- Comment #13 from mmitchel at gcc dot gnu dot org 2008-09-23 18:38 --- The C++ WP draft I have (a bit old) says: If the second and third operands are lvalues and have the same type, the result is of that type and is an lvalue and it is a bit-field if the second or the third operand is a bit-field, or if both are bit-fields. So, I don't see why: (x ? c.i : a) = y; should not be valid In C++, type does not include the number of bits in the bit-field. I think think the expression x ? c.i : a is an lvalue bit-field of type int. On that basis, I think the gimplifier (including C++-specific hooks thereto) should handle converting down to whatever representation GENERIC requires. I'd expect something like: t = SAVE_EXPR (y), x ? (c.i = (int-of-N-bits) t) : (a = t), t We could also do this in the FE proper (before GENERIC) if required; we would fix up the conditional expression after working out whether it's being used as an lvalue or an rvalue. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37146
[Bug debug/37410] DW_TAG_imported_module is not in its DW_TAG_lexical_block
--- Comment #4 from jakub at gcc dot gnu dot org 2008-09-23 18:48 --- Just a few nits: 1) why do you need to call nreverse? I don't think the order of vars in BLOCK_VARS matters, and when you call nreverse you reorder them all but the one you added anyway 2) have you checked that gimple_current_bind_expr + gimple_bind_block is sufficient? I believe during gimplification even artificial, block-less GIMPLE_BINDs can be added. So I think more robust would be to call gimple_bind_expr_stack (), and walk the vector from the last GIMPLE_BIND in it up to the first, stopping when you find a GIMPLE_BIND with non-NULL gimple_bind_block. 3) I think usually gcc uses _1 suffixed helper functions instead of _real 4) I think defining IMPORTED_DECL_NS_NAME is overkill, just use DECL_NAME 5) there are a few minor formatting issues, e.g. missing space in *expr_p,0 or IMPORTED_DECL_NS_DECL (using_directive) = TREE_OPERAND (*expr_p, 0) (where IMPORTED_DECL_NS_DECL (using_directive) = TREE_OPERAND (*expr_p, 0); should be written). -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37410
[Bug fortran/37626] Internal compiler error triggered by gfortran PACK intrinsic
--- Comment #1 from dominiq at lps dot ens dot fr 2008-09-23 18:48 --- On ppc/intel Darwin9, I get pr37626.f90: In function 'unique_a': pr37626.f90:42: internal compiler error: in gfc_conv_descriptor_data_get, at fortran/trans-array.c:147 with 4.2.3, 4.3.2, and trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37626
[Bug c++/37533] ICE with parallel for loop
--- Comment #2 from jakub at gcc dot gnu dot org 2008-09-23 18:58 --- Subject: Bug 37533 Author: jakub Date: Tue Sep 23 18:57:18 2008 New Revision: 140613 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140613 Log: PR c++/37533 * semantics.c (finish_omp_for): If processing_template_decl, just build MODIFY_EXPR for init instead of calling cp_build_modify_expr. * g++.dg/gomp/pr37533.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr37533.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37533
[Bug c++/37533] ICE with parallel for loop
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-09-20 03:06:23 |2008-09-23 19:02:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37533
[Bug c++/37533] ICE with parallel for loop
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-23 19:03 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37533
[Bug bootstrap/37627] In function `fold_builtin_1': undefined reference to `mpfr_j0'
--- Comment #2 from brian at dessent dot net 2008-09-23 19:23 --- Subject: Re: New: In function `fold_builtin_1': undefined reference to `mpfr_j0' It sounds like you have an older system copy of mpfr in /usr/lib which is being used instead of the one you built. Use --with-mpfr=foo where foo is the prefix you specified when you configured mpfr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37627
[Bug testsuite/37623] builtin-math-4 tests fail
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-09-23 19:26 --- That probably means you have too old mpfr. Yes, I just upgraded from 2.2.x to 2.3.1 on Solaris and the failure vanished. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37623
[Bug testsuite/37622] gcc.dg: failure reported for direct2s.c
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-09-23 19:27 --- Clean build from a source tree that was the result of svn switching to the 4.3.2 release tag (was previously a 4.3.0 release I think). Update your tree with contrib/gcc_update. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37622
[Bug fortran/37626] ICE for automatic deallocation of character result variable
--- Comment #2 from burnus at gcc dot gnu dot org 2008-09-23 19:43 ---
It fails for the following assert:
gfc_conv_descriptor_data_get (tree desc)
{
tree field, type, t;
type = TREE_TYPE (desc);
gcc_assert (GFC_DESCRIPTOR_TYPE_P (type));
Reduced test case:
function unique_A (x) result (x_unique)
implicit none
character(*), dimension(:), intent(in) :: x
character(LEN(x)), dimension(:), allocatable :: x_unique
character(LEN(x)), dimension(5) :: x_sorted
logical, dimension(4):: mask
mask = (/ x_sorted(2:5) /= x_sorted(1:4) /)
allocate(x_unique(COUNT(mask)))
end function unique_A
If one one changes the program to function x_unique(x), i.e. sym ==
sym-result, it works. The same is true if the character length is explicitly
set for x_unique (or for x, which implies the latter).
Debugging shows the following call tree for x_unique:
#0 gfc_conv_descriptor_data_get
#1 gfc_trans_dealloc_allocated
#2 gfc_trans_deferred_array
Thus the ICE happens for the automatic deallocation of x_unique. But as
x_unique is a result variable that should not happen!
Patch:
--- trans-array.c (Revision 140615)
+++ trans-array.c (Arbeitskopie)
@@ -5754,7 +5754,7 @@ gfc_trans_deferred_array (gfc_symbol * s
gfc_add_expr_to_block (fnblock, tmp);
}
- if (sym-attr.allocatable !sym-attr.save)
+ if (sym-attr.allocatable !sym-attr.save !sym-attr.result)
{
tmp = gfc_trans_dealloc_allocated (sym-backend_decl);
gfc_add_expr_to_block (fnblock, tmp);
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
OtherBugsDependingO||32834
nThis||
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
GCC build triplet|x86_64-gentoo-linux |
GCC host triplet|x86_64-gentoo-linux |
GCC target triplet|x86_64-gentoo-linux |
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2008-09-23 19:43:30
date||
Summary|Internal compiler error |ICE for automatic
|triggered by gfortran PACK |deallocation of character
|intrinsic |result variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37626
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #55 from jason at gcc dot gnu dot org 2008-09-23 20:43 ---
It seems reasonable to me for try { X } catch... to mean X when
-fno-exceptions. We don't need to error except on throw.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug regression/37629] New: auto-import of constant data results in a crash at runtime
Compiling ffmpeg (see
http://sourceforge.net/tracker2/?func=detailaid=2118261group_id=202880atid=983354)
under mingw-w64 into a DLL results in a runtime crash involving two dlls.
in libavutil.dll:
const uint8_t ff_log2_tab[256];
in libavcodec.dll:
extern const uint8_t ff_log2_tab[256];
static inline int av_log2(unsigned int)
{
...
}
which uses the ff_log2_tab array. The ff_log2_tab array is auto-imported from
libavutil into libavcodec.
When av_log2 is called the resulting program crashes. The workaround is to
explicitly import ff_log2_tab into libavcodec via:
__declspec(dllimport) const uint8_t ff_log2_tab[256];
If this is done the crash goes away.
This worked fine in gcc 4.3.
--
Summary: auto-import of constant data results in a crash at
runtime
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jkolb at wsi dot com
GCC build triplet: x86_64-mingw-32
GCC host triplet: x86_64-mingw-32
GCC target triplet: x86_64-mingw-32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37629
[Bug c++/37590] g++ should emit different debug info for variable's type
--- Comment #7 from tromey at gcc dot gnu dot org 2008-09-23 20:48 --- Jan Tom, could you elaborate why x1 and x2 should be printed differently? Jan I do not say they should not but I do not see a clear reason for either way. My view is that whatis should print the declared type, as much as possible. Note that this is a contrived example. Here, it hardly matters. However, there are many cases where whatis shows something incomprehensible to the user. Jan Should we also try to record the source name of this variable? Jan #define OBJECT_VAR(object, var) object ## _ ## var Jan int OBJECT_VAR (window, width); Yeah, we can't do a perfect job all the time. We have to print something, of course, and I suggest using the tokens naming the type (or variable) after preprocessing -- mostly because that is easy and gets the right answer when the user does not do cpp tricks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37590
[Bug testsuite/37630] New: gcc.dg/20001012-1.c depends on IEEE FP encoding
and thus fails on platforms which don't use IEEE FP encoding such as VAX. -- Summary: gcc.dg/20001012-1.c depends on IEEE FP encoding Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matt at 3am-software dot com GCC build triplet: x86-64--netbsd GCC host triplet: x86_64--netbsd GCC target triplet: vax--netbsdelf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37630
[Bug tree-optimization/18046] Missed jump threading optimization
--- Comment #13 from law at redhat dot com 2008-09-23 21:55 ---
Subject: Re: Missed jump threading optimization
steven at gcc dot gnu dot org wrote:
--- Comment #12 from steven at gcc dot gnu dot org 2008-09-21 13:58
---
tree PRE now *does* handle the partially redundant global variable load. This
is the .final_cleanup dump:
;; Function bar (bar)
bar ()
{
int prephitmp.13;
bb 2:
prephitmp.13 = i;
switch (prephitmp.13) default: L1, case 0: L0
L0:
foo ();
prephitmp.13 = i;
L1:
switch (prephitmp.13) default: L5, case 0: L4
L4:
foo (); [tail call]
L5:
return;
}
But we still miss the jump threading opportunity.
Thanks for the update. One blocking issue out of the way
Things have changed a lot since that original bug report. I believe the
best solution for this particular case is to lower the switch statements
early enough to expose the conditionals to DOM VRP.
The 2nd best approach would be to extend VRP to create a range for the
default case of a SWITCH and extend the jump threading code in
tree-vrp.c to handle switch statements (they're currently ignored). The
biggest difficulty here would be to avoid dropping to varying too
quickly. I think you'd want to sort the cases, then build up a range
containing all the cases. If you get a gap in the range, you drop to
varying. If after extracting all the ranges you haven't dropped to
varying, then you invert the range and create the appropriate ASSERT_EXPRs.
I'm not currently working on either solution.
jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18046
[Bug c++/37631] New: non-volatile asm passes volatile asm (-O3)
I'm not 100% sure this is a bug; it seems like one.
A non-volatile asm passes a volatile asm. Intuitively, it seems a volatile asm
should be a pretty heavy barrier.
As a workaround, declaring both volatile does limit code motion, but also
limits the optimizer more than just keeping the relative order of the two
volatiles.
Happens with this compiler:
$ g++ -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --with-tune=pentium4 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
also happens with (replacing add with addq may be needed):
$g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /build/configure --prefix=/usr/local/build
--target=x86_64-unknown-linux-gnu --disable-nls --enable-threads=posix
--enable-symvers=gnu --enable-__cxa_atexit --enable-c99 --enable-long-long
--build=i686-host_pc-linux-gnu --host=i686-host_pc-linux-gnu --disable-multilib
--enable-shared=libgcc,libmudflap,libssp,libstdc++
--enable-languages=c,c++,fortran --with-sysroot=/usr/grte/v1
--with-root-prefix=/usr/grte/v1 --with-native-system-header-dir=/include
--with-local-prefix=/
Thread model: posix
gcc version 4.2.2
Build using Makefile:
CXX = g++
CXXFLAGS = -Wall -O3
all:bug.dis bug.E
bug:bug.cc Makefile
$(CXX) $(CXXFLAGS) -o bug bug.cc
bug.E: bug.cc Makefile
$(CXX) $(CXXFLAGS) -E -o bug.E bug.cc
bug.dis:bug
objdump --disassemble bug bug.dis
Input program (this is not the CPP output, but the input program does not use
CPP and this has a potentially-useful comment):
//
// The following program compiled with g++ -O3 produces the code shown below.
// Note the add of %fs appears in the source between calls to Now() but appears
// in the object code before the first call to Now(). The asm with %fs is not
// not itself volatile so it may be moved with respect to other code (the
// original code is more complicated), but it seems surprising it passes the
// volatile asm in Now().
//
// 8048397: 64 03 05 00 00 00 00add%fs:0x0,%eax
// 804839e: 89 45 f0mov%eax,-0x10(%ebp)
// 80483a1: e8 aa ff ff ff call 8048350 _Z3Nowv
// 80483a6: 89 c3 mov%eax,%ebx
// 80483a8: 89 d6 mov%edx,%esi
// 80483aa: 90 nop
// 80483ab: 8b 45 f0mov-0x10(%ebp),%eax
// 80483ae: 8b 38 mov(%eax),%edi
// 80483b0: 90 nop
// 80483b1: e8 9a ff ff ff call 8048350 _Z3Nowv
//
static inline int *XX() {
long long int offset = 64;
int *val;
asm /*not volatile*/ (add %%fs:0, %0 : =r(val) : 0(offset));
return val;
}
const int kCallsPerTrial = 30;
typedef long long Tsc;
__attribute__((__noinline__)) Tsc Now() {
unsigned int eax_lo, edx_hi;
asm volatile(rdtsc : =a (eax_lo), =d (edx_hi));
Tsc now = ((Tsc)eax_lo) | ((Tsc)(edx_hi) 32);
return now;
}
int g_sink;
bool RunTest(Tsc *tsc, int n) {
int val;
for (int i = 0; i n; ++i) {
Tsc start = Now();
asm volatile(nop ::: memory);
val = *XX();
asm volatile(nop ::: memory);
Tsc stop = Now();
g_sink = val;
*tsc++ = start;
*tsc++ = stop;
}
return true;
}
int main(int argc, char **argv) {
Tsc tsc[2 * kCallsPerTrial];
RunTest(tsc, kCallsPerTrial);
}
--
Summary: non-volatile asm passes volatile asm (-O3)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pardo at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37631
[Bug testsuite/37630] gcc.dg/20001012-1.c depends on IEEE FP encoding
--- Comment #1 from joseph at codesourcery dot com 2008-09-23 22:24 --- Subject: Re: New: gcc.dg/20001012-1.c depends on IEEE FP encoding As a maintainer of a non-mainstream target you'll need to submit testsuite patches to disable tests inapplicable on your target; it's unlikely anyone else will fix the testsuite bugs you report. For this one, for example, an ieee_float_format effective-target keyword might be the right way to go (you could implement that effective-target as allowing all non-VAX targets if you wish). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37630
[Bug middle-end/37509] __sync_fetch_and_xxx generates relocatable symbols
--- Comment #5 from timothy dot krause at shaw dot ca 2008-09-23 22:53 --- Setting CFLAGS=-m32 -march=i686 -O2 fixed the problem for host=i686-pc-linux-gnu target=i686-pc-linux-gnu I later noticed that configure has a --with-cpu option. This generates a -mcpu=i?86 option which also works but is depricated. Thanks to Paolo Carlini for this fix. -- timothy dot krause at shaw dot ca changed: What|Removed |Added GCC host triplet||i686-pc-linux-gnu GCC target triplet||i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37509
[Bug middle-end/37509] __sync_fetch_and_xxx generates relocatable symbols
--- Comment #6 from timothy dot krause at shaw dot ca 2008-09-23 22:56 --- (In reply to comment #5) Setting CFLAGS=-m32 -march=i686 -O2 fixed the problem for host=i686-pc-linux-gnu target=i686-pc-linux-gnu I later noticed that configure has a --with-cpu option. This generates a -mcpu=i?86 option which also works but is deprecated. Thanks to Paolo Carlini for this fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37509
[Bug libgcj/18266] GCJ: Using references drops finalizers causing all apps to eventually crash ( SIGSEGV in GC_register_finalizer_inner () )
--- Comment #19 from Hans dot Boehm at hp dot com 2008-09-23 23:39 --- I looked at this a bit, trying to remind myself of the logic. I'm not positive, but it looks plausible to me that doing without the finalizer might work for most applications. Historically, the finalizer was the only cleanup mechanism for heavy locks. But that turned out to be insuficient, and maybe_remove_all_heavy was added. It tries to occasionally remove long lists of heavy locks, that were still observed to accumulate in some cases. That's probably usually enough to keep the list from growing without bounds. I would however worry about an application that holds one or more locks indefinitely. At that point, the heavy_count for the corresponding hash entry never drops to zero, and maybe_remove_all_heavy won't do its job for that entry. Thus I think the list of heavy locks for that entry will grow without (reasonable) bounds. As a result, I don't think this is curently a fully general fix, though it may work for many applications. I'm not positive, but it seems likely to me that one might be able to avoid this poisoning effect of a single-in-use lock by adding in-use bits to heavy locks, which are protected on the lock bit by the hash entry. This may allow unused entries to be cleaned up even if one or two heavy locks in the chain are held. That might turn this into a real fix, if it's not possible to fix this elsewhere. It might also simplify the code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266
[Bug c++/37631] non-volatile asm passes volatile asm (-O3)
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-23 23:50 --- A volatile asm is not a full barrier. Please read http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Extended-Asm.html. Note that even a volatile asm instruction can be moved relative to other code, including across jump instructions. For example, on many targets there is a system register which can be set to control the rounding mode of floating point operations. This came about with the fix for PR 17884. *** This bug has been marked as a duplicate of 17884 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37631
[Bug tree-optimization/17884] asm 'volatile' is not honored as documented
--- Comment #26 from pinskia at gcc dot gnu dot org 2008-09-23 23:50 --- *** Bug 37631 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pardo at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17884
[Bug middle-end/37509] __sync_fetch_and_xxx generates relocatable symbols
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-09-23 23:51 --- You want --with-arch or -march=i686. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37509
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #11 from janis at gcc dot gnu dot org 2008-09-24 00:16 --- Created an attachment (id=16398) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16398action=view) yet another C testcase I still don't understand what's going on, but have a new testcase that demonstrates a few things. By looking at tree dumps and the generated code I see that sometimes one of the comparisions of al[0], al[1], and al[2] is skipped, which I don't understand, but apparently which one is skipped is affected by -ffast-math, or is perhaps a Heisenbug that just looks as if it's affected by -ffast-math. Some interesting output from the test: elm3b149% $GCC -v Using built-in specs. Target: powerpc64-linux Configured with: /home/janis/gcc_trunk_anonsvn/gcc/configure --prefix=/home/janis/tools/gcc-trunk-anonsvn --build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32 --with-as=/home/janis/tools/binutils-20080903/bin/as --with-ld=/home/janis/tools/binutils-20080903/bin/ld --enable-threads=posix --enable-shared --enable-__cxa_atexit --enable-languages=c,c++,fortran --with-gmp=/home/janis/tools/gmp-mpfr-32 --with-mpfr=/home/janis/tools/gmp-mpfr-32 --with-long-double-128 --enable-secureplt --disable-libstdcxx-pch Thread model: posix gcc version 4.4.0 20080923 (experimental) [trunk revision 140601] (GCC) elm3b149% $GCC -O1 -ffast-math 37449-3.c -lm a.out cn = -2 neig = 3 Aborted elm3b149% $GCC -O1 37449-3.c -lm a.out cn = -2 neig = 2 elm3b149% $GCC -DDBG -O1 -ffast-math 37449-3.c -lm a.out cn = -2 tt= -1.0472 al[0] = 0.5 al[1] = 0.5 al[2] = -1 neig = 2 elm3b149% $GCC -DDBG -O1 37449-3.c -lm a.out cn = -2 tt= 1.0472 al[0] = 0.5 al[1] = -1 al[2] = 0.5 neig = 2 elm3b149% $GCC -DCN=-1. -O1 -ffast-math 37449-3.c -lm a.out cn = -1 neig = 2 This won't make sense without looking at the testcase, but the test should get the same result whenever cn = -1., but it gets different results for -1. and -2., going through different paths through the generated code. Notice also that the values of the array al[] are switched around depending on the options used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-09-24 00:21 --- The one thing which we should do after sra_early is another pass_rename_ssa_copies so we get more correct variable/debug names. (but that is not the issue). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug bootstrap/37632] New: Darwin bootstrap failure, ld: bl out of range
Configured with
#!/bin/tcsh
/bin/rm -rf *; ../../mainline/configure CC='gcc -mcpu=970 -m64'
--build=powerpc64-apple-darwin9.5.0 --host=powerpc64-apple-darwin9.5.0
--target=powerpc64-apple-darwin9.5.0 --with-gmp-include=/sw/include/
--with-gmp-lib=/sw/lib/ppc64 --with-mpfr-include=/sw/include/
--with-mpfr-lib=/sw/lib/ppc64 --prefix=/pkgs/gcc-4.4.0-64
--with-libiconv-prefix=/usr --with-system-zlib; make -j 4 bootstrap
BOOT_LDFLAGS='-Wl,-search_paths_first' build.log (make install) (make
-k -j 8 check RUNTESTFLAGS=--target_board 'unix{-mcpu=970/-m64}'
check.log ; make mail-report.log)
Failed near end of stage1 with
[descartes:objdirs/mainline/gcc] lucier% set path=(/pkgs/gcc-4.3.2-64/bin/
$path)
[descartes:objdirs/mainline/gcc] lucier% gcc -mcpu=970 -m64 -g
-fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -o cc1-dummy c-lang.o
stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o
c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o
c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o
darwin-c.o rs6000-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o
dummy-checksum.o main.o tree-browser.o libbackend.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ./../intl/libintl.a
/usr/lib/libiconv.dylib ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
-L/sw/lib/ppc64 -L/sw/lib/ppc64 -lmpfr -lgmp -L/sw/lib/ppc64 -L/sw/lib/ppc64
-lmpfr -lgmp -v
Using built-in specs.
Target: powerpc64-apple-darwin9.5.0
Configured with: ../gcc-4.3.2/configure --enable-checking=release
--build=powerpc64-apple-darwin9.5.0 --host=powerpc64-apple-darwin9.5.0
--target=powerpc64-apple-darwin9.5.0 --with-gmp-include=/sw/include/
--with-gmp-lib=/sw/lib/ppc64 --with-mpfr-include=/sw/include/
--with-mpfr-lib=/sw/lib/ppc64 --prefix=/pkgs/gcc-4.3.2-64
Thread model: posix
gcc version 4.3.2 (GCC)
COMPILER_PATH=/pkgs/gcc-4.3.2-64/libexec/gcc/powerpc64-apple-darwin9.5.0/4.3.2/:/pkgs/gcc-4.3.2-64/libexec/gcc/powerpc64-apple-darwin9.5.0/4.3.2/:/pkgs/gcc-4.3.2-64/libexec/gcc/powerpc64-apple-darwin9.5.0/:/pkgs/gcc-4.3.2-64/lib/gcc/powerpc64-apple-darwin9.5.0/4.3.2/:/pkgs/gcc-4.3.2-64/lib/gcc/powerpc64-apple-darwin9.5.0/
LIBRARY_PATH=/pkgs/gcc-4.3.2-64/lib/gcc/powerpc64-apple-darwin9.5.0/4.3.2/:/pkgs/gcc-4.3.2-64/lib/gcc/powerpc64-apple-darwin9.5.0/4.3.2/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.5' '-mcpu=970' '-m64' '-g'
'-fkeep-inline-functions' '-DIN_GCC' '-W' '-Wall' '-Wwrite-strings'
'-Wstrict-prototypes' '-Wmissing-prototypes' '-Wcast-qual'
'-Wold-style-definition' '-Wc++-compat' '-Wmissing-format-attribute'
'-pedantic' '-Wno-long-long' '-Wno-variadic-macros' '-Wno-overlength-strings'
'-fno-common' '-DHAVE_CONFIG_H' '-o' 'cc1-dummy' '-L/sw/lib/ppc64'
'-L/sw/lib/ppc64' '-L/sw/lib/ppc64' '-L/sw/lib/ppc64' '-v'
/pkgs/gcc-4.3.2-64/libexec/gcc/powerpc64-apple-darwin9.5.0/4.3.2/collect2
-dynamic -arch ppc64 -macosx_version_min 10.5.5 -weak_reference_mismatches
non-weak -o cc1-dummy -lcrt1.10.5.o -L/sw/lib/ppc64 -L/sw/lib/ppc64
-L/sw/lib/ppc64 -L/sw/lib/ppc64
-L/pkgs/gcc-4.3.2-64/lib/gcc/powerpc64-apple-darwin9.5.0/4.3.2
-L/pkgs/gcc-4.3.2-64/lib/gcc/powerpc64-apple-darwin9.5.0/4.3.2/../../..
c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o
c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o
c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o
c-parser.o darwin-c.o rs6000-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o
c-omp.o dummy-checksum.o main.o tree-browser.o libbackend.a ../libcpp/libcpp.a
../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ./../intl/libintl.a
/usr/lib/libiconv.dylib ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
-lmpfr -lgmp -lmpfr -lgmp -lgcc_s.10.5 -lgcc -lSystemStubs -lSystem
ld: bl out of range (-19728300 max is +/-16M) from _add_builtin_function_common
at 0x1012EC858 in __text of libbackend.a(langhooks.o) to _decl_attributes at
0x10001C3C0 in __text of attribs.o in _add_builtin_function_common from
libbackend.a(langhooks.o)
collect2: ld returned 1 exit status
--
Summary: Darwin bootstrap failure, ld: bl out of range
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
GCC build triplet: powerpc64-apple-darwin9.5.0
GCC host triplet: powerpc64-apple-darwin9.5.0
GCC target triplet: powerpc64-apple-darwin9.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37632
[Bug inline-asm/37621] Missing documentation for x86 inline assembler modifiers
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-24 00:35 --- IIRC these are not documented because they can and will change at any time and don't always produce correct code. Also you can use most of the builtin functions to get the same as the inline-asm ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37621
[Bug bootstrap/37632] Darwin bootstrap failure, ld: bl out of range
--- Comment #1 from lucier at math dot purdue dot edu 2008-09-24 00:53 --- I forgot to mention the linker version: [descartes:objdirs/mainline/gcc] lucier% ld -v @(#)PROGRAM:ld PROJECT:ld64-85.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37632
[Bug target/37633] New: [4.4 Regression] wrong register use on sh64
Currently many tests for string builtin functions fail on
sh64-unknown-linux-gnu. Here is a small test case:
extern void abort (void);
char buf[64];
int
main (void)
{
__builtin_strcpy (buf, mystring);
if (strcmp (buf, mystring) != 0)
abort ();
__builtin_strcpy (buf, mystring);
if (strcmp (buf, mystring) != 0)
abort ();
return 0;
}
With -O3, the register R11 is used to hold 8-byte of mystring
for the first __builtin_strcpy call. The value in R11 is reused
with the 2nd __builtin_strcpy call.
When strcmp is dynamically linked, the upper 32-bit of R11 is
clobbered by the first call of strcmp. Then the 2nd strcmp
returns false.
The backend defines HARD_REGNO_CALL_PART_CLOBBERED so to notify
that the upper 32-bit of R11 may be clobbered for SHmedia:
/* Only the lower 32-bits of R10-R14 are guaranteed to be preserved
across SHcompact function calls. We can't tell whether a called
function is SHmedia or SHcompact, so we assume it may be when
compiling SHmedia code with the 32-bit ABI, since that's the only
ABI that can be linked with SHcompact code. */
#define HARD_REGNO_CALL_PART_CLOBBERED(REGNO,MODE) \
(TARGET_SHMEDIA32 \
GET_MODE_SIZE (MODE) 4 \
(((REGNO) = FIRST_GENERAL_REG + 10 \
(REGNO) = FIRST_GENERAL_REG + 15) \
|| TARGET_REGISTER_P (REGNO) \
|| (REGNO) == PR_MEDIA_REG))
but it seems that now HARD_REGNO_CALL_PART_CLOBBERED doesn't affect
the register allocation.
--
Summary: [4.4 Regression] wrong register use on sh64
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
GCC target triplet: sh64-unknow-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37633
[Bug target/37633] [4.4 Regression] wrong register use on sh64
-- kkojima at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37633
[Bug bootstrap/37632] Darwin bootstrap failure, ld: bl out of range
--- Comment #2 from lucier at math dot purdue dot edu 2008-09-24 01:34 --- And it doesn't happen if I use Apple's builtin gcc-4.0.1. Blah. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37632
[Bug target/37137] [4.4 Regression] unrecognized command line option -minterlink-mips16
--- Comment #5 from nemet at gcc dot gnu dot org 2008-09-24 02:09 --- I am seeing this too with a 4.1 system compiler. It seems that CFLAGS_FOR_TARGET is incorrectly (?) used for building libiberty in stage1 (all-stage1-libiberty). This is not a target library but a sort of build library built with the system compiler. I think this happens because STAGE1_LIBCFLAGS is incorrectly set to CFLAGS_FOR_TARGET. For example, I can build all-stage1-libiberty if I run make with STAGE1_LIBCFALGS=. -- nemet at gcc dot gnu dot org changed: What|Removed |Added CC||nemet at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37137
[Bug target/37633] [4.4 Regression] wrong register use on sh64
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37633
[Bug target/37629] auto-import of constant data results in a crash at runtime
--- Comment #1 from dannysmith at users dot sourceforge dot net 2008-09-24 03:12 --- This bug is linker related. It is fixed on 32-bit windows by this patch http://sourceware.org/ml/binutils-cvs/2007-10/msg2.html Have you tried with recent binutils and explict -Wl,--enable-auto-import switch? Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37629
[Bug tree-optimization/37539] [4.4 Regression] Hang for -O3
--- Comment #7 from jakub at gcc dot gnu dot org 2008-09-24 03:24 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37539
[Bug c++/37553] [4.3/4.4 Regression] ICE in build_c_cast
-- doug dot gregor at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |doug dot gregor at gmail dot |dot org |com Status|NEW |ASSIGNED Last reconfirmed|2008-09-17 21:02:56 |2008-09-24 04:37:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37553
[Bug fortran/37498] [4.4 Regression] Incorrect array value returned - 4.3 ABI Broken
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2008-09-24 05:14 --- Created an attachment (id=16399) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16399action=view) New patch that is much better I could not submit this to the list for approval, my email is not working. Regression tested on x86-64. This patch reverts a lot of the previous and results in a much cleaner fix that works with the namelist_14 example. If I can get approval I will commit. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Attachment #16342|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37498
