[Bug bootstrap/32835] [4.3 regression] Bootstrap failure under SGI Irix
--- Comment #3 from P dot Schaffnit at access dot rwth-aachen dot de 2007-08-07 06:45 --- Hi! Fixed: revision 127237 builds smoothly Thanks! Philippe === gcc Summary === # of expected passes43910 # of unexpected failures33 # of unexpected successes 2 # of expected failures 97 # of unresolved testcases 9 # of untested testcases 35 # of unsupported tests 398 /usr/local_people/Philippe/Compilation/gcc/xgcc version 4.3.0 20070806 (experimental) === gfortran Summary === # of expected passes19925 # of unexpected failures93 # of unexpected successes 7 # of expected failures 9 # of unsupported tests 28 /usr/local_people/Philippe/Compilation/gcc/testsuite/gfortran/../../gfortran version 4.3.0 20070806 (experimental) -- P dot Schaffnit at access dot rwth-aachen dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32835
[Bug middle-end/33007] [4.3 Regression] Revision 127185 causes NINT to ICE
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-07 03:23 --- This is a bug in the middle-end: /* If we were unable to expand via the builtin, stop the sequence (without outputting the insns) and call to the library function with the stabilized argument list. */ end_sequence (); target = expand_call (exp, target, target == const0_rtx); This is not true, there is no call here really. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |middle-end Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-08-07 03:23:02 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33007
[Bug fortran/33007] [4.3 Regression] Revision 127185 causes NINT to ICE
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-07 03:15 --- t.f90: In function 'foo': t.f90:11: internal compiler error: tree check: expected call_expr, have nop_expr in expand_call, at calls.c:1885 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=33007
[Bug fortran/33007] [4.3 Regression] Revision 127185 causes NINT to ICE
--- Comment #1 from hjl at lucon dot org 2007-08-07 03:11 --- It happens on both Linux/i686 and Linux/x86-64. -- hjl at lucon dot org changed: What|Removed |Added GCC target triplet|i686-pc-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33007
[Bug fortran/33007] New: [4.3 Regression] Revision 127185 causes NINT to ICE
Revision 127185: http://gcc.gnu.org/ml/gcc-cvs/2007-08/msg00077.html causes [EMAIL PROTECTED] 481.wrf]$ cat foo.f90 SUBROUTINE foo(st_levels_input, num_st_levels_input) IMPLICIT NONE INTEGER , INTENT(IN) :: num_st_levels_input INTEGER , DIMENSION(1:num_st_levels_input) , INTENT(INOUT) :: st_levels_input INTEGER :: lout , lin REAL :: temp IF ( st_levels_input(lout) .GT. st_levels_input(lin) ) THEN temp = st_levels_input(lout) st_levels_input(lin) = NINT(temp) END IF END SUBROUTINE foo [EMAIL PROTECTED] 481.wrf]$ ../127185/usr/bin/gfortran -DSPEC_CPU_LOGICAL_STRICT -frecord-marker=4 -S foo.f90 -m32 -O foo.f90: In function âfooâ: foo.f90:10: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED] 481.wrf]$ -- Summary: [4.3 Regression] Revision 127185 causes NINT to ICE Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33007
[Bug fortran/32732] [Bind C] Character scalars are passed as arrays
--- Comment #6 from kargl at gcc dot gnu dot org 2007-08-07 00:29 --- Hopefully, Chris' patch fixed this bug. If problems re-appear we can also re-open the PR. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32732
[Bug fortran/32732] [Bind C] Character scalars are passed as arrays
--- Comment #5 from kargl at gcc dot gnu dot org 2007-08-07 00:27 --- Subject: Bug 32732 Author: kargl Date: Tue Aug 7 00:27:25 2007 New Revision: 127265 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127265 Log: 2007-08-06 Christopher D. Rickett <[EMAIL PROTECTED]> PR fortran/32732 * trans-expr.c (gfc_conv_scalar_char_value): Convert the tree and actual arg expressions for scalar characters passed by-value to bind(c) routines. (gfc_conv_function_call): Call gfc_conv_scalar_char_value. * trans.h: Add prototype for gfc_conv_scalar_char_value. * trans-decl.c (generate_local_decl): Convert by-value character dummy args of bind(c) procedures using gfc_conv_scalar_char_value. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32732
[Bug target/30961] [4.1/4.2/4.3 regression] redundant reg/mem stores/moves
--- Comment #22 from hjl at lucon dot org 2007-08-07 00:22 --- There are 2 issues, convert and load. They may be caused by different patches and should be tracked separately when doing binary search. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug fortran/32860] Support %ld (for "long") for gfc_warning
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-06 23:46 --- Hi Tobias, what do you think about this patch? I think it would add %u for unsigned int, %lu for unsigned long int, %li and %ld for long int. I have no time to test, but I think it should work ok (I wrote the current version of these functions...) Index: error.c === --- error.c (revision 127224) +++ error.c (working copy) @@ -113,19 +113,13 @@ error_string (const char *p) /* Print a formatted integer to the error buffer or output. */ -#define IBUF_LEN 30 +#define IBUF_LEN 60 static void -error_integer (int i) +error_uinteger (unsigned long int i) { char *p, int_buf[IBUF_LEN]; - if (i < 0) -{ - i = -i; - error_char ('-'); -} - p = int_buf + IBUF_LEN - 1; *p-- = '\0'; @@ -141,6 +135,22 @@ error_integer (int i) error_string (p + 1); } +static void +error_integer (long int i) +{ + unsigned long int u; + + if (i < 0) +{ + u = (unsigned long int) -i; + error_char ('-'); +} + else +u = i; + + error_uinteger (u); +} + /* Show the file, where it was included, and the source line, give a locus. Calls error_printf() recursively, but the recursion is at @@ -368,7 +378,8 @@ show_loci (locus *l1, locus *l2) static void ATTRIBUTE_GCC_GFC(2,0) error_print (const char *type, const char *format0, va_list argp) { - enum { TYPE_CURRENTLOC, TYPE_LOCUS, TYPE_INTEGER, TYPE_CHAR, TYPE_STRING, + enum { TYPE_CURRENTLOC, TYPE_LOCUS, TYPE_INTEGER, TYPE_UINTEGER, + TYPE_LONGINT, TYPE_ULONGINT, TYPE_CHAR, TYPE_STRING, NOTYPE }; struct { @@ -377,6 +388,9 @@ error_print (const char *type, const cha union { int intval; + unsigned int uintval; + long int longintval; + unsigned long int ulongintval; char charval; const char * stringval; } u; @@ -453,6 +467,18 @@ error_print (const char *type, const cha arg[pos].type = TYPE_INTEGER; break; + case 'u': + arg[pos].type = TYPE_UINTEGER; + + case 'l': + c = *format++; + if (c == 'u') + arg[pos].type = TYPE_ULONGINT; + else if (c == 'i' || c == 'd') + arg[pos].type = TYPE_LONGINT; + else + gcc_unreachable (); + case 'c': arg[pos].type = TYPE_CHAR; break; @@ -499,6 +525,18 @@ error_print (const char *type, const cha arg[pos].u.intval = va_arg (argp, int); break; + case TYPE_UINTEGER: + arg[pos].u.uintval = va_arg (argp, unsigned int); + break; + + case TYPE_LONGINT: + arg[pos].u.longintval = va_arg (argp, long int); + break; + + case TYPE_ULONGINT: + arg[pos].u.ulongintval = va_arg (argp, unsigned long int); + break; + case TYPE_CHAR: arg[pos].u.charval = (char) va_arg (argp, int); break; @@ -568,6 +606,19 @@ error_print (const char *type, const cha case 'i': error_integer (spec[n++].u.intval); break; + + case 'u': + error_uinteger (spec[n++].u.uintval); + break; + + case 'l': + format++; + if (*format == 'u') + error_uinteger (spec[n++].u.ulongintval); + else + error_integer (spec[n++].u.longintval); + break; + } } -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-06 23:46:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32860
[Bug c++/31749] [4.1/4.2/4.3 regression] ICE with invalid redeclaration of builtin
--- Comment #6 from aaw at gcc dot gnu dot org 2007-08-06 23:17 --- Created an attachment (id=14030) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14030&action=view) Fix for PR 31749. This patches fixes this PR and includes some ambiguous decl cleanup as well. Submission pending completion of full testsuite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31749
[Bug c++/32970] [4.3 Regression] C++ frontend can not handle vector pointer constant parameter
--- Comment #1 from janis at gcc dot gnu dot org 2007-08-06 23:15 --- A regression hunt of mainline on powerpc-linux identified the following patch, where the compiler went from compiling in a reasonable time to taking more than three seconds for the submitter's testcase: r117696 | bonzini | 2006-10-13 15:59:03 + (Fri, 13 Oct 2006) http://gcc.gnu.org/viewcvs?view=rev&rev=117696 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32970
[Bug fortran/30947] intrinsic: ALARM
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-08-06 23:05 --- This should fix the remaining part. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30947
[Bug fortran/30947] intrinsic: ALARM
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-08-06 23:03 --- Subject: Bug 30947 Author: fxcoudert Date: Mon Aug 6 23:02:38 2007 New Revision: 127259 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127259 Log: PR fortran/30947 * iresolve.c (gfc_resolve_alarm_sub): Suffix the subroutine name with the kind of the STATUS argument. * intrinsics/signal.c: Create specific versions of alarm_sub and alarm_sub_int according to the integer kind of the last argument. * gfortran.map (GFORTRAN_1.0): Remove _gfortran_alarm_sub and _gfortran_alarm_sub_int, add _gfortran_alarm_sub_i4, _gfortran_alarm_sub_i8, _gfortran_alarm_sub_int_i4 and _gfortran_alarm_sub_int_i8. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/iresolve.c trunk/libgfortran/ChangeLog trunk/libgfortran/gfortran.map trunk/libgfortran/intrinsics/signal.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30947
[Bug fortran/30948] intrinsic: CHDIR
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-08-06 22:45 --- Last bit fixed: http://gcc.gnu.org/viewcvs?view=rev&revision=127257 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30948
[Bug fortran/30933] intrinsic: EXIT
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-08-06 22:44 --- Subject: Bug 30933 Author: fxcoudert Date: Mon Aug 6 22:44:27 2007 New Revision: 127257 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127257 Log: PR fortran/30933 * intrinsic.c (add_functions): Fix name of argument to CHDIR. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30933
[Bug fortran/30933] intrinsic: EXIT
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-08-06 22:29 --- Last bit fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30933
[Bug fortran/30933] intrinsic: EXIT
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-08-06 22:29 --- Subject: Bug 30933 Author: fxcoudert Date: Mon Aug 6 22:29:24 2007 New Revision: 127256 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127256 Log: PR fortran/30933 * iresolve.c (gfc_resolve_exit): Convert argument to default integer kind. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/iresolve.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30933
[Bug c++/32839] internal compiler error: Segmentation fault (templates)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32839
[Bug pch/13676] GCC failes to recognize files ending in .hpp as headers to be precompiled
--- Comment #18 from pinskia at gcc dot gnu dot org 2007-08-06 21:43 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13676
[Bug objc/32995] False warning when implementing an instance method called `dealloc'
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-06 21:40 --- well to some extend dealloc is special method which is why the warning is there. Also dealloc does not belong to the the original Object class (which is based on the old NX Object base class). This is true of the NeXT runtime Object too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|x86_64-linux-gnu| Summary|False warning when |False warning when |implementing an instance|implementing an instance |method called `dealloc' |method called `dealloc' http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32995
[Bug target/30961] [4.1/4.2/4.3 regression] redundant reg/mem stores/moves
--- Comment #21 from pluto at agmk dot net 2007-08-06 21:39 --- rev. 101665: convert:movl%edi, -4(%rsp) movl%edi, -20(%rsp) movss -4(%rsp), %xmm0 ret load: movzwl (%rdi), %eax ret rev. 101666 (-fforce-mem removal): convert:movl%edi, -4(%rsp) movl%edi, -20(%rsp) movss -4(%rsp), %xmm0 ret load: movzwl (%rdi), %eax movw%ax, -2(%rsp) movzwl %ax, %eax ret rev. 116656 (patch for PR27567): convert:movl%edi, -4(%rsp) movss -4(%rsp), %xmm1 movaps %xmm1, %xmm0 ret load: movzwl (%rdi), %eax movw%ax, -2(%rsp) movzwl %ax, %eax ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug c++/31749] [4.1/4.2/4.3 regression] ICE with invalid redeclaration of builtin
--- Comment #5 from aaw at gcc dot gnu dot org 2007-08-06 21:24 --- No segfault, but it does give an "is already declared in this scope" error. Contrary to the claim in the initial bug submission, this is valid code. >From paragraph 10, section 7.3.3 of the C++ standard: Since a using-declaration is a declaration, the restrictions on declarations of the same name in the same declarative region (3.3) also apply to using-declarations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31749
[Bug fortran/31059] Detect nonconforming assignment of allocatable arrays
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-06 21:18 --- I don't think it's a duplicate, and I don't think it has anything to do with allocatable either: $ cat b.f90 subroutine foo(n) integer, allocatable :: ivec(:) integer :: jvec(n) allocate (ivec(n)) ivec = [1,2,3] write (*,*) ivec jvec = [1,2,3] write (*,*) jvec end program test call foo (2) end $ gfortran -fbounds-check b.f90 && ./a.out 1 2 1 2 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org OtherBugsDependingO||27766 nThis|| Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31059
[Bug fortran/30802] out of bounds error in allocatable array not picked up with -fbounds-check
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-06 21:13 --- It's not about being allocatable, it's the I/O operation that doesn't perform the necessary check: $ cat a.f90 real :: x(2,2) x = 0. print *, x(5,:) x(5,:) = 1. end $ gfortran -fbounds-check a.f90 && ./a.out 0.00 5.8787666E-39 At line 4 of file a.f90 Fortran runtime error: Array reference out of bounds for array 'x', upper bound of dimension 1 exceeded -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30802
[Bug fortran/29828] [F2003] MIN and MAX with character variables
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-06 20:49 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29828
[Bug fortran/29828] [F2003] MIN and MAX with character variables
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-06 20:47 --- Subject: Bug 29828 Author: fxcoudert Date: Mon Aug 6 20:47:17 2007 New Revision: 127252 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127252 Log: PR fortran/29828 * trans.h (gfor_fndecl_string_minmax): New prototype. * trans-decl.c (gfor_fndecl_string_minmax): New variable. (gfc_build_intrinsic_function_decls): Create gfor_fndecl_string_minmax. * check.c (gfc_check_min_max): Allow for character arguments. * trans-intrinsic.c (gfc_conv_intrinsic_minmax_char): New function. (gfc_conv_intrinsic_function): Add special case for MIN and MAX intrinsics with character arguments. * simplify.c (simplify_min_max): Add simplification for character arguments. * intrinsics/string_intrinsics.c (string_minmax): New function and prototype. * gfortran.map (GFORTRAN_1.0): Add _gfortran_string_minmax * gfortran.dg/minmax_char_1.f90: New test. * gfortran.dg/minmax_char_2.f90: New test. * gfortran.dg/min_max_optional_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/min_max_optional_4.f90 trunk/gcc/testsuite/gfortran.dg/minmax_char_1.f90 trunk/gcc/testsuite/gfortran.dg/minmax_char_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/gfortran.map trunk/libgfortran/intrinsics/string_intrinsics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29828
[Bug java/32758] ecj1 hangs
--- Comment #8 from andreast at gcc dot gnu dot org 2007-08-06 20:34 --- Happens since r125624. Same situation on ppc-linux (32-bit) In the libjava testsuite you'll see the following test cases failing since then: FAIL: noclass execution - gij test FAIL: pr11951 execution - gij test FAIL: throwit execution - gij test FAIL: pr29812 execution - gij test FAIL: ExtraClassLoader execution - source compiled test FAIL: ExtraClassLoader -findirect-dispatch execution - source compiled test FAIL: ExtraClassLoader -O3 execution - source compiled test FAIL: ExtraClassLoader -O3 -findirect-dispatch execution - source compiled test -- andreast at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-07-24 14:33:31 |2007-08-06 20:34:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32758
[Bug fortran/32985] COMMON checking: TYPE with(out) SEQUENCE/bind(C), ALLOCATABLE
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-06 20:18 --- Besides default initializers (TODO), I also forgot about the following, to be added after the if clause of previous patch: else if (csym->ts.type == BT_DERIVED && csym->ts.derived->attr.alloc_comp) { gfc_error ("Derived type variable '%s' at %L in COMMON has " "an ultimate component that is allocatable", csym->name, &csym->declared_at); } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32985
[Bug testsuite/32843] [4.3 Regression] : libffi.call/return_sc.c
--- Comment #15 from doko at gcc dot gnu dot org 2007-08-06 20:13 --- Subject: Bug 32843 Author: doko Date: Mon Aug 6 20:13:06 2007 New Revision: 127249 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127249 Log: - Revert the changes for PR testsuite/32843, not needed on the branch. Modified: branches/ubuntu/gcc-4_2-branch/libffi/ChangeLog branches/ubuntu/gcc-4_2-branch/libffi/src/x86/ffi.c branches/ubuntu/gcc-4_2-branch/libffi/src/x86/sysv.S branches/ubuntu/gcc-4_2-branch/libffi/testsuite/libffi.call/return_sc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
[Bug target/31868] Non-Linux DWARF EH x86-64 targets have broken crtend.o
--- Comment #3 from hjl at gcc dot gnu dot org 2007-08-06 19:58 --- Subject: Bug 31868 Author: hjl Date: Mon Aug 6 19:58:11 2007 New Revision: 127248 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127248 Log: 2007-08-06 H.J. Lu <[EMAIL PROTECTED]> Daniel Jacobowitz <[EMAIL PROTECTED]> PR target/31868 * config.gcc (x86_64-*-freebsd*): Add i386/t-crtstuff to tmake_file. (x86_64-*-netbsd*): Likewise. (x86_64-*-linux*): Likewise. (x86_64-*-kfreebsd*-gnu): Likewise. (x86_64-*-knetbsd*-gnu): Likewise. (i[34567]86-*-solaris2.1[0-9]*): Likewise. * config/i386/t-linux64 (CRTSTUFF_T_CFLAGS): Removed. * config/i386/t-crtstuff (CRTSTUFF_T_CFLAGS): Update comments. Add -fno-asynchronous-unwind-tables. * config/t-freebsd (CRTSTUFF_T_CFLAGS_S): Add $(CRTSTUFF_T_CFLAGS). * config/t-libc-ok (CRTSTUFF_T_CFLAGS_S): Likewise. * config/t-lynx (CRTSTUFF_T_CFLAGS_S): Likewise. * config/t-netbsd (CRTSTUFF_T_CFLAGS_S): Likewise. * config/t-svr4 (CRTSTUFF_T_CFLAGS_S): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/i386/t-crtstuff trunk/gcc/config/i386/t-linux64 trunk/gcc/config/t-freebsd trunk/gcc/config/t-libc-ok trunk/gcc/config/t-lynx trunk/gcc/config/t-netbsd trunk/gcc/config/t-svr4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31868
[Bug fortran/32985] COMMON checking: TYPE with(out) SEQUENCE/bind(C), ALLOCATABLE
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-06 19:23 --- Patch for the first part. Missing: Check for default initializer. Index: resolve.c === --- resolve.c (revision 127246) +++ resolve.c (working copy) @@ -610 +610 @@ resolve_common_blocks (gfc_symtree *comm - gfc_symbol *sym; + gfc_symbol *sym, *csym; @@ -618,0 +619,14 @@ resolve_common_blocks (gfc_symtree *comm +for (csym = symtree->n.common->head; csym; csym = csym->common_next) + { + printf("DEBUG '%s' - derived=%s?\n",csym->name, csym->ts.type == BT_DERIVED?"yes":"no"); + /* Derived type names must have the SEQUENCE attribute. */ + if (csym->ts.type == BT_DERIVED + && !(csym->ts.derived->attr.sequence +|| csym->ts.derived->attr.is_bind_c)) + { + gfc_error ("Derived type variable '%s' in COMMON at %L has " + "neither the SEQUENCE nor the BIND(C) attribute", + csym->name, &csym->declared_at); + } + } + Index: match.c === --- match.c (revision 127246) +++ match.c (working copy) @@ -2635,8 +2634,0 @@ gfc_match_common (void) - /* Derived type names must have the SEQUENCE attribute. */ - if (sym->ts.type == BT_DERIVED && !sym->ts.derived->attr.sequence) - { - gfc_error ("Derived type variable in COMMON at %C does not " -"have the SEQUENCE attribute"); - goto cleanup; - } - -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32985
[Bug middle-end/32940] REG_POINTER attribute on DECL_ARTIFICIAL pointers
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-06 19:22 --- This patch helps more than just PR 28690 as we now have the ablity to use r0 more for the index which causes us to use one less callee saved register in some cases and reduces the stack size. I saw that result while compiling tramp3d. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32940
[Bug other/32998] -frecord-gcc-switches issues
--- Comment #3 from roland at redhat dot com 2007-08-06 19:19 --- Absolute file names are a very bad idea. That makes for gratuitous differences in builds due to the build or source directory name, i.e. unrepeatable builds. The names in .debug_line and .debug_info are already expected by post-processing tools and taken care of. Do not add another location in the object that might contain absolute file names. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998
[Bug target/30961] [4.1/4.2/4.3 regression] redundant reg/mem stores/moves
--- Comment #20 from pluto at agmk dot net 2007-08-06 18:28 --- (In reply to comment #19) > If we can find which patch causes this regression, it will help find a > solution for 4.2. > i'll we do a bisect hunting... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug fortran/33001] error with hexadecimal DATA
--- Comment #7 from patchapp at dberlin dot org 2007-08-06 18:20 --- Subject: Bug number PR33001 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00374.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug target/30961] [4.1/4.2/4.3 regression] redundant reg/mem stores/moves
--- Comment #19 from hjl at lucon dot org 2007-08-06 18:02 --- If we can find which patch causes this regression, it will help find a solution for 4.2. -- hjl at lucon dot org changed: What|Removed |Added Known to fail|4.0.2 4.1.2 4.2.1 |4.0.2 4.1.2 4.2.1 4.3.0 Summary|[4.1/4.2 regression]|[4.1/4.2/4.3 regression] |redundant reg/mem |redundant reg/mem |stores/moves|stores/moves Version|4.2.0 |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug target/30961] [4.1/4.2 regression] redundant reg/mem stores/moves
--- Comment #18 from pluto at agmk dot net 2007-08-06 17:49 --- (In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #15) > > > (In reply to comment #14) > > > > (In reply to comment #13) > > > > > Created an attachment (id=13550) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13550&action=view) [edit] > > > > > An experimental patch > > > > > > > > > > This patch works for the testcase. > > > > > > > > i've applied this patch to 4.2.1 and compile testcases: > > > > > > > > convert/m32/m64 look fine. load/m32/m64 still look unoptimal. > > > > > > > > > > Gcc 4.3 works: > > > > naturally but its not even been released yet. > > users awaiting regression fixes for released compilers ;) > > > > Load is fixed by dataflow merge. > Dear H.J.Lu, i'm not asking about 4.3 because it's far away future and dataflow merge won't be a part of next 4.2 release. i understand that developers love to play with unstable tree instead of backporting fixes but we're awaiting regression fixes for released compilers. after 4.3 release you'll jump to 4.4 and leave 4.3 regressions in the same way as you left 4.2 regressions. so, how we can motivate the gcc team to fix regressions in non-trunk tree? do you expect donations? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug fortran/32933] ICE in simplify_subreg with -fdefault-integer-8
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-06 17:35 --- *** Bug 33006 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||michael dot a dot richmond ||at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32933
[Bug fortran/33006] internal compiler error: in simplify_subreg, at simplify-rtx.c:4676
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 17:35 --- >3. The program was compiled with the flag "-fdefault-integer-8". It does not > produce the error without this flag. Yes we know, we are trying to resolve more and more of these -fdefault-integer-8 bugs. *** This bug has been marked as a duplicate of 32933 *** -- 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=33006
[Bug fortran/18026] boz initialization of REALs fails
--- Comment #15 from kargl at gcc dot gnu dot org 2007-08-06 17:32 --- *** Bug 33002 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
[Bug fortran/33002] Hexadecimal DATA incorrect
--- Comment #5 from kargl at gcc dot gnu dot org 2007-08-06 17:32 --- *** This bug has been marked as a duplicate of 18026 *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33002
[Bug fortran/33006] New: internal compiler error: in simplify_subreg, at simplify-rtx.c:4676
When I attempt to compile the program listed below I get the following message: a.f90: In function 'MAIN__': a.f90:2: internal compiler error: in simplify_subreg, at simplify-rtx.c:4676 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. The conditions were: 1. The August 3 version of gcc and gfortran were used. The problem does not occur with the July 27 version. 2. It was run on an SGI box under Debian Linux. I have not tested it on other processors. 3. The program was compiled with the flag "-fdefault-integer-8". It does not produce the error without this flag. 4. If I replace z = MAX(x,y) with i = MAX(j, k) the problem disappears. PROGRAM test z = MAX(x,y) END PROGRAM test -- Summary: internal compiler error: in simplify_subreg, at simplify-rtx.c:4676 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33006
[Bug fortran/18026] boz initialization of REALs fails
--- Comment #14 from kargl at gcc dot gnu dot org 2007-08-06 17:30 --- *** Bug 33001 has been marked as a duplicate of this bug. *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||sliwa at cft dot edu dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18026
[Bug fortran/33001] error with hexadecimal DATA
--- Comment #6 from kargl at gcc dot gnu dot org 2007-08-06 17:30 --- *** This bug has been marked as a duplicate of 18026 *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug c++/32970] [4.3 Regression] C++ frontend can not handle vector pointer constant parameter
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|powerpc64-unknown-linux-gnu | GCC host triplet|powerpc64-unknown-linux-gnu | GCC target triplet|spu-unknown-elf | Keywords||ice-on-valid-code Known to fail||4.3.0 Known to work||4.1.1 Summary|C++ frontend can not handle |[4.3 Regression] C++ |vector pointer constant |frontend can not handle |parameter |vector pointer constant ||parameter Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32970
[Bug other/32998] -frecord-gcc-switches issues
--- Comment #2 from bkoz at gcc dot gnu dot org 2007-08-06 16:16 --- thanks for adding this bug report here and ccing me. Is there an easy way to separate out the include and link (-I, -L) bits from the macro defines and compiler option flags? Could the just the include bits be put into one string? When doing this does it make sense to define the base_dir and then use it as a substitution instead of putting in absolute addresses everywhere? This might cut down on size. > I think that in order to fix this the .GCC.command.line section creation > code will have to be made more complex and have access to the entire command > line options table. When I submitted the original patch to create this > feature I wanted to keep things simple, so I did not try to do this. This seems like a pretty smart strategy for getting this in. However can you expand on your comment above? What do you mean by "have access to the entire command line options table?" Would you dump the entire table? -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2007-08-06 16:16 --- Not that I know. For my purposes, I use a hand-modified version of the _mingw.h header; maybe more recent versions of mingw have been fixed. Still, current trunk doesn't work with older mingw (more than a few months back). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug c++/32984] add checking for array new & delete
--- Comment #7 from dcb314 at hotmail dot com 2007-08-06 16:06 --- (In reply to comment #6) > This is one which you need huge dataflow analysis Doubtful. Yes/No/Don't know flag on each pointer data member of a class would be some of it. > and whole program to detect this problem. I'd be happy with a one file solution to this problem, as I hope my original problem report made clear. In summary, my customer doesn't have HP kit, valgrind is run time and not compile time, the compiler isn't going to be fixed anytime soon so I feel a Perl script may be invented. > So closing as won't fix. Fair enough. Point taken. I'll try a Perl script. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32984
[Bug c++/32898] [4.2/4.3 regression] Definition of variable N::i outside namespace N not rejected
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 15:53 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-06 15:53:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32898
[Bug tree-optimization/19910] [4.2 regression] ICE with -ftree-loop-linear
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-08-06 15:47 --- Fixed for the trunk. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2/4.3 regression] ICE|[4.2 regression] ICE with - |with -ftree-loop-linear |ftree-loop-linear http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19910
[Bug debug/32563] [4.2/4.3 regression] ICE on pointer arithmetic
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 15:44 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-06 15:44:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32563
[Bug c++/32674] [4.1/4.2/4.3 regression] ICE in lvalue_p_1 initialising static variable inside template class
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 15:38 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-08-06 15:38:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32674
[Bug c++/32567] [4.3 regression] ICE on invalid use of parameter pack
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 15:29 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-06 15:29:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32567
[Bug c++/32566] [4.3 regression] ICE with invalid specialization of variadic template
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 15:28 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-06 15:28:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32566
[Bug tree-optimization/30394] [4.3 Regression] FAIL: gcc.c-torture/execute/pr15262-1.c execution at -O2, -O3 and -Os
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-06 15:25 --- Fixed. And has been for a while. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30394
[Bug c++/31749] [4.1/4.2/4.3 regression] ICE with invalid redeclaration of builtin
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-06 15:12 --- I no longer get a segfault for the trunk for the first testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31749
[Bug preprocessor/30786] [4.1/4.2/4.3 Regression] ICE on _Pragma at end of file
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Keywords||error-recovery http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30786
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-08-06 14:57 --- Has this been fixed now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug c++/28558] [4.0/4.1/4.2/4.3 regression] Trouble with __attribute__ and non-PODs
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-06 14:41 --- We get a different ICE now: t1.cc:4: internal compiler error: same canonical type node for different types A and A Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-08-18 04:13:29 |2007-08-06 14:41:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28558
[Bug c++/5458] address of overloaded template function as argument for template
--- Comment #12 from rodolfo at rodsoft dot org 2007-08-06 14:18 --- This is an yet simpler case where this bug shows up: template void foo(T); void foo(int); void bar() { &foo; } i686-pc-linux-gnu-g++-4.2.1 fails with: teste.cpp: In function void bar(): teste.cpp:6: error: statement cannot resolve address of overloaded function -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5458
[Bug libobjc/30731] [4.3 Regression] Warnings while compiling libobjc with the uleb128 changes
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-08-06 14:18 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30731
[Bug libobjc/30731] [4.3 Regression] Warnings while compiling libobjc with the uleb128 changes
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-06 14:18 --- Subject: Bug 30731 Author: pinskia Date: Mon Aug 6 14:17:59 2007 New Revision: 127242 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127242 Log: 2007-08-06 Andrew Pinski <[EMAIL PROTECTED]> PR libobjc/30731 * exception.c (parse_lsda_header): Use _uleb128_t/_sleb128_t instead of _Unwind_Word for variables which are used in read_uleb128/read_sleb128. (PERSONALITY_FUNCTION): Likewise. Modified: trunk/libobjc/ChangeLog trunk/libobjc/exception.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30731
[Bug fortran/32626] Run-time check for recursive functions
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-06 14:06:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32626
[Bug c++/5458] address of overloaded template function as argument for template
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-08-06 13:58 --- *** Bug 33004 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rodolfo at rodsoft dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5458
[Bug c++/33004] Cannot resolve call to overloaded function and template functions)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 13:58 --- *** This bug has been marked as a duplicate of 5458 *** -- 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=33004
[Bug c++/11407] [DR 115] Function cannot be resolved
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-08-06 13:57 --- *** Bug 33005 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rodolfo at rodsoft dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11407
[Bug c++/33005] Cannot specialize template function with address operator
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 13:57 --- *** This bug has been marked as a duplicate of 11407 *** -- 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=33005
[Bug c++/33005] New: Cannot specialize template function with address operator
The code below doesn't compile under gcc-4.2.1 on a i686-pc-linux-gnu template void foo(T); void bar() { &foo; } The compiler returns the following error message: teste.cpp: In function void bar(): teste.cpp:4: error: statement cannot resolve address of overloaded function As we're specifying a complete template function specialization, its address should be returned correctly, and there's no overloaded function in scope, there's nothing to resolve. -- Summary: Cannot specialize template function with address operator Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rodolfo at rodsoft dot org 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=33005
[Bug c++/33004] New: Cannot resolve call to overloaded function and template functions)
The following code doesn't compile under gcc-4.2.1 on i686-pc-linux-gnu: template void foo(T); void foo(int); void bar() { &foo; } According to the discussion that began on thread http://gcc.gnu.org/ml/gcc/2007-07/msg00663.html, then resumed on thread http://gcc.gnu.org/ml/gcc/2007-07/msg00946.html, the compiler should accept the code as valid, returning the address of 'void foo(int)'. -- Summary: Cannot resolve call to overloaded function and template functions) Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rodolfo at rodsoft dot org 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=33004
[Bug fortran/29458] Spurious -Wuninitialized warning for implied do-loop counter
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-01-31 23:01:50 |2007-08-06 13:47:12 date|| Target Milestone|4.2.2 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29458
[Bug bootstrap/32840] bootstrap broken on ix86-linux-gnu targets with --enable-targets=all
--- Comment #1 from hjl at lucon dot org 2007-08-06 13:44 --- Can you verify if it is the same as PR 31868? There is a a patch for PR 31868. -- hjl at lucon dot org changed: What|Removed |Added CC||hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32840
[Bug testsuite/32843] [4.3 Regression] : libffi.call/return_sc.c
--- Comment #14 from aph at gcc dot gnu dot org 2007-08-06 13:35 --- In addition: I suspect that this bug also is manifested on x86 Darwin, but my patch should not affect that system at all, and therefore I suspect that this bug is still manifested on that system. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
[Bug debug/32990] [Regression] gdb has symbol table issues
--- Comment #2 from drow at gcc dot gnu dot org 2007-08-06 13:21 --- Subject: Re: New: [Regression] gdb has symbol table issues On Sat, Aug 04, 2007 at 11:13:11PM -, scovich at gmail dot com wrote: > When debugging code produced by g++-4.3.0-20070716 the debugger regularly > outputs the following error message when stopping at breakpoints or examining > stack frames: > > error: warning: (Internal error: pc 0x419e59 in read in psymtab, but not in > symtab.) This is more likely to be a bug in GDB than in GCC. We would need at least the debugging info (readelf -wf) from the compilation unit containing that address. But the GDB developers will probably not be able to help you without a testcase, either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32990
[Bug fortran/18850] padding within a sequence type
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-06 13:15 --- Maybe I'm completely off, but isn't the -fpack-derived option what is needed to play with this padding? (it's hard for me to tell exactly, because I don't really read assembly) If so, could we close the PR? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18850
[Bug fortran/33001] error with hexadecimal DATA
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-06 13:06 --- > The numbers are 32-bit, so why an overflow? huge(0): 2147483647 ! biggest (positive) number fitting into integer(4) Z'': 4294967295 I would argue that 4294967295 is bigger than 2147483647. If one allows the overflow or regards it as bit pattern, one obtains "-1". This is also what one gets for -fno-range-check. The program is simply invalid though as vendor extension many compilers allow it. One can discuss about the default behaviour in gfortran [write to the mailing list and not here], but the current behaviour has some merits, though I think one should point to the option which allows the compilation (see patch in comment #2). - (In reply to comment #4) > d1mach.f:2: fatal error: gfc_todo: Not Implemented: Initialization of > overlapping variables This was fixed meanwhile. gfortran 4.3 does not have this error any more. 4.3 binaries are available at: http://gcc.gnu.org/wiki/GFortranBinaries -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug target/32951] missed memcpy -> movdqa optimization.
--- Comment #4 from pluto at agmk dot net 2007-08-06 12:56 --- (In reply to comment #3) > Subject: Re: missed memcpy -> movdqa optimization. > > On 6 Aug 2007 12:42:18 -, pluto at agmk dot net > <[EMAIL PROTECTED]> wrote: > > moreover i'm wondering why gcc uses movdqa for unaligned loads? > > Because __m128i is assumed to be aligned. so, as far i can see currently there's no way to generate movdqu load with and __builtin_memcpy( &__m128i, unaligned_ptr, 16 ) and i must write a short inline assembly for this purpose. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32951
[Bug testsuite/32843] [4.3 Regression] : libffi.call/return_sc.c
--- Comment #13 from aph at gcc dot gnu dot org 2007-08-06 12:53 --- > The 32bit psABI specifies Integral Arguments as 'Functions pass all > integer-valued > arguments as words, expanding or padding signed or unsigned bytes and > halfwords as needed'. For return values the best I can find is 'A function > that > returns an integral or pointer value places its result in register %eax.' > Both are not exactly clear whether sign- or zero-extension is required. On the contrary, this implies very strongly to me that all integer-valued arguments are passed as words, fully sign- or zero-extended for their type. To read this in any other way strikes me as perverse. If we are not correctly sign- or zero-extendening return values we have broken the ABI. To suggest that this sign- or zero-extension does not apply to return values is also perverse. -- aph at gcc dot gnu dot org changed: What|Removed |Added CC||aph at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
[Bug fortran/33002] Hexadecimal DATA incorrect
--- Comment #4 from burnus at gcc dot gnu dot org 2007-08-06 12:49 --- Using REAL RMACH(5) DATA RMACH(1) / Z'0080' / is invalid Fortran 77/90/95/2003 as Fortran only allows: "If a data-stmt-constant is a boz-literal-constant, the corresponding variable shall be of type integer. The boz-literal-constant is treated as if it were an int-literal-constant with a kind-param that specifies the representation method with the largest decimal exponent range supported by the processor." Gfortran interprets DATA RMACH(1) / Z'0080' / as rmach(1) = real(int(Z'0080', maximallyNeededKind)) which is ok as the program is invalid and thus undfefined. Other compilers interpret it as bit pattern. The result is are 8388608. respectively 1.1754944E-38. Solution for Fortran 90/95/2003: Replace DATA RMACH(1) / Z'0080' / by RMACH(1) = transfer( Z'0080', rmach) I think nonetheless that gfortran misbehaves. Expected: - With -std=f95 etc. give a warning or an error - With -std=gnu allow it (maybe with warning?) and tread as transfer(Z'...', 0.0) to be compatible with the other compilers. NAG f95 gives always the error: Error: Data-stmt-value incompatible with data-stmt-object whereas, e.g., g95 and ifort give a warning for -std=f95 and have the same result as with TRANSFER. Warning (160): BOZ constant conversion at (1) is nonstandard Warning: Fortran 95 does not allow boz constant in this context. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org GCC build triplet|x86_64-redhat-linu | GCC host triplet|x86_64-redhat-linu | GCC target triplet|x86_64-redhat-linu | Keywords||diagnostic Summary|64-bit hexadecimal DATA |Hexadecimal DATA incorrect |incorrect | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33002
[Bug fortran/33001] error with hexadecimal DATA
--- Comment #3 from sliwa at cft dot edu dot pl 2007-08-06 12:41 --- 1. The attached d1mach.f works fine with g77. 2. The numbers are 32-bit, so why an overflow? Maybe the number is extended as a signed number (padded with ones), and the conversion is unsigned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug target/32951] missed memcpy -> movdqa optimization.
--- Comment #2 from pluto at agmk dot net 2007-08-06 12:42 --- thanks for ths explanation about aligned attribute. moreover i'm wondering why gcc uses movdqa for unaligned loads? it should use movdqu for *((__m128i*)ptr) and _mm_set_epi8(ptr[15],...,ptr[0]). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32951
[Bug testsuite/32843] [4.3 Regression] : libffi.call/return_sc.c
--- Comment #12 from aph at gcc dot gnu dot org 2007-08-06 12:48 --- Subject: Bug 32843 Author: aph Date: Mon Aug 6 12:48:07 2007 New Revision: 127241 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127241 Log: PR testsuite/32843 * src/x86/sysv.S (ffi_closure_raw_SYSV): Handle FFI_TYPE_UINT8, FFI_TYPE_SINT8, FFI_TYPE_UINT16, FFI_TYPE_SINT16, FFI_TYPE_UINT32, FFI_TYPE_SINT32. Modified: trunk/libffi/ChangeLog trunk/libffi/src/x86/sysv.S -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
[Bug fortran/33001] error with hexadecimal DATA
--- Comment #4 from sliwa at cft dot edu dot pl 2007-08-06 12:45 --- With -fno-range-check I get: d1mach.f: In function 'd1mach': d1mach.f:2: fatal error: gfc_todo: Not Implemented: Initialization of overlapping variables compilation terminated. See also bug #33002. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug target/32951] missed memcpy -> movdqa optimization.
--- Comment #3 from pinskia at gmail dot com 2007-08-06 12:43 --- Subject: Re: missed memcpy -> movdqa optimization. On 6 Aug 2007 12:42:18 -, pluto at agmk dot net <[EMAIL PROTECTED]> wrote: > moreover i'm wondering why gcc uses movdqa for unaligned loads? Because __m128i is assumed to be aligned. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32951
Re: [Bug target/32951] missed memcpy -> movdqa optimization.
On 6 Aug 2007 12:42:18 -, pluto at agmk dot net <[EMAIL PROTECTED]> wrote: > moreover i'm wondering why gcc uses movdqa for unaligned loads? Because __m128i is assumed to be aligned. -- Pinski
[Bug c++/33003] missed diagnostic about unused variable.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-06 12:33 --- To the developer (and me), x is not unused. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33003
[Bug fortran/33001] error with hexadecimal DATA
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-06 12:11 --- DATA LARGE(1), LARGE(2) / Z'', Z'7FEF' / Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1) The error message is correct: You cannot fit the number into an INTEGER(4) as this is bigger than "HUGE(0)". As the overflow is intended, one can use -fno-range-check to disable this checking and thus the error message. I think one should do here the same as in primary.c and add the following to the error message: --- arith.c (revision 127237) +++ arith.c (working copy) @@ -1983,3 +1983,4 @@ arith_error (arith rc, gfc_typespec *fro case ARITH_OVERFLOW: - gfc_error ("Arithmetic overflow converting %s to %s at %L", + gfc_error ("Arithmetic overflow converting %s to %s at %L. This check " +"can be disabled with the option -fno-range-check", gfc_typename (from), gfc_typename (to), where); -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org GCC build triplet|x86_64-redhat-linux | GCC host triplet|x86_64-redhat-linux | GCC target triplet|x86_64-redhat-linux | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug c++/33003] New: missed diagnostic about unused variable.
class X { public: static X& instance(); static void init(); private: X(); }; void f() { X& x = X::instance(); x.init(); } in this case the 'x' variable is initialized and unused. gcc-4.2 accepts this w/o any warning at -Wall -Wextra but vs2005-express reports warning C4189 at warning level 4. -- Summary: missed diagnostic about unused variable. Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33003
[Bug middle-end/28690] [4.2/4.3 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #41 from paolo dot bonzini at lu dot unisi dot ch 2007-08-06 11:52 --- Subject: Re: [4.2/4.3 Regression] Performace problem with indexed load/stores on powerpc > This is now more like a meta-bug, see the other two bugs which are opened for > the current issues (yes both are assigned to me and both are actively being > worked on, well one is depend on the other but still being worked on). Ah, I see. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug c++/22256] diagnostic shows wrong type for cast operator
--- Comment #6 from pcarlini at suse dot de 2007-08-06 11:52 --- The subtle issue here is that this specific error message should be emitted *only* when the incorrectly specified return type doesn't match, thus a plain error instead of a pedwarn: case sfk_conversion: if (type && !same_type_p (type, optype)) error ("operator %qT declared to return %qT", optype, type); else if (type) pedwarn ("return type specified for %", optype); type = optype; but for some reason the thing doesn't work... I'm looking a bit into it. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22256
[Bug middle-end/28690] [4.2/4.3 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #40 from pinskia at gcc dot gnu dot org 2007-08-06 11:35 --- (In reply to comment #39) > committed?? This is now more like a meta-bug, see the other two bugs which are opened for the current issues (yes both are assigned to me and both are actively being worked on, well one is depend on the other but still being worked on). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug fortran/33002] 64-bit hexadecimal DATA incorrect
--- Comment #3 from sliwa at cft dot edu dot pl 2007-08-06 11:21 --- Now I see that 32-bit data is incorrect also. DATA RMACH(1) / Z'0080' / DATA RMACH(2) / Z'7F7F' / DATA RMACH(3) / Z'3380' / DATA RMACH(4) / Z'3400' / DATA RMACH(5) / Z'3E9A209B' / -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33002
[Bug fortran/33002] 64-bit hexadecimal DATA incorrect
--- Comment #2 from sliwa at cft dot edu dot pl 2007-08-06 11:18 --- There is also bug #33001. Both the bugs together make life difficult. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33002
[Bug pch/13676] GCC failes to recognize files ending in .hpp as headers to be precompiled
--- Comment #17 from gerald at gcc dot gnu dot org 2007-08-06 11:10 --- Subject: Bug 13676 Author: gerald Date: Mon Aug 6 11:10:19 2007 New Revision: 127239 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127239 Log: PR pch/13676 * doc/invoke.texi: Add .hp, .hxx, .hpp, .h, .HPP, .tcc as c++ header. cp: * lang-specs.h: Add .hp, .hxx, .hpp, .h, .HPP, .tcc as c++ header. * g++spec.c (lang_specific_driver): Check them. Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/g++spec.c trunk/gcc/cp/lang-specs.h trunk/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13676
[Bug fortran/33002] 64-bit hexadecimal DATA incorrect
--- Comment #1 from sliwa at cft dot edu dot pl 2007-08-06 11:15 --- Created an attachment (id=14029) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14029&action=view) sample source that demonstrates the problem This is a SLATEC machine file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33002
[Bug fortran/33002] New: 64-bit hexadecimal DATA incorrect
Statements like: DATA DMACH(1) / Z'0010' / DATA DMACH(2) / Z'7FEF' / DATA DMACH(3) / Z'3CA0' / DATA DMACH(4) / Z'3CB0' / DATA DMACH(5) / Z'3FD34413509F79FF' / generate incorrect data. -- Summary: 64-bit hexadecimal DATA incorrect Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sliwa at cft dot edu dot pl GCC build triplet: x86_64-redhat-linu GCC host triplet: x86_64-redhat-linu GCC target triplet: x86_64-redhat-linu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33002
[Bug fortran/33001] error with hexadecimal DATA
--- Comment #1 from sliwa at cft dot edu dot pl 2007-08-06 11:03 --- Created an attachment (id=14028) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14028&action=view) sample source that does not compile This is a SLATEC machine file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug fortran/33001] New: error with hexadecimal DATA
d1mach.f:90.43: DATA LARGE(1), LARGE(2) / Z'', Z'7FEF' / 1 Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1) -- Summary: error with hexadecimal DATA Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sliwa at cft dot edu dot pl GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug fortran/32926] Internal compiler error in the middle of a sizeable package build
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-06 09:49 --- OK, I downloaded GlobSol and have a reduced testcase: $ cat pr32926.f90 subroutine foo (fcn) external fcn contains subroutine bar call fcn end subroutine bar end subroutine foo $ gfortran pr32926.f90 pr32926.f90: In function bar: pr32926.f90:4: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:890 The backtrace is: Breakpoint 1, fancy_abort ( file=0xb03900 "../../../trunk2/gcc/fortran/trans-decl.c", line=890, function=0xb03f60 "gfc_get_symbol_decl") at ../../../trunk2/gcc/diagnostic.c:654 654 { (gdb) where #0 fancy_abort (file=0xb03900 "../../../trunk2/gcc/fortran/trans-decl.c", line=890, function=0xb03f60 "gfc_get_symbol_decl") at ../../../trunk2/gcc/diagnostic.c:654 #1 0x0048c5a3 in gfc_get_symbol_decl (sym=0xe8e1d0) at ../../../trunk2/gcc/fortran/trans-decl.c:888 #2 0x0048ec58 in gfc_conv_function_val (se=0x7fff83f5a240, sym=0x37a) at ../../../trunk2/gcc/fortran/trans-expr.c:1252 #3 0x004909b6 in gfc_conv_function_call (se=0x7fff83f5a240, sym=0xe8e1d0, arg=0x0, append_args=0x0) at ../../../trunk2/gcc/fortran/trans-expr.c:2459 #4 0x004ab86f in gfc_trans_call (code=0xe8ee30, dependency_check=0 '\0') at ../../../trunk2/gcc/fortran/trans-stmt.c:331 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32926
[Bug fortran/32801] USE of ISO_C_BINDING, ONLY: C_LOC causes compiler seg fault
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-08-06 09:20 --- Without any more news, let's consider this fixed. Douglas, if it so happens that your bug wasn't fixed by the patch, please reopen this bug-report. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32801
[Bug c++/19532] cp/pt.c mentions a function that has been removed.
--- Comment #3 from pcarlini at suse dot de 2007-08-06 09:19 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19532