[Bug bootstrap/32835] [4.3 regression] Bootstrap failure under SGI Irix

2007-08-06 Thread P dot Schaffnit at access dot rwth-aachen dot de


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread hjl at lucon dot org


--- 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

2007-08-06 Thread hjl at lucon dot org
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

2007-08-06 Thread kargl at gcc dot gnu dot org


--- 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

2007-08-06 Thread kargl at gcc dot gnu dot org


--- 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

2007-08-06 Thread hjl at lucon dot org


--- 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

2007-08-06 Thread fxcoudert at gcc dot gnu dot org


--- 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

2007-08-06 Thread aaw at gcc dot gnu dot org


--- 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

2007-08-06 Thread janis at gcc dot gnu dot org


--- 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

2007-08-06 Thread fxcoudert at gcc dot gnu dot org


--- 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

2007-08-06 Thread fxcoudert at gcc dot gnu dot org


--- 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

2007-08-06 Thread fxcoudert at gcc dot gnu dot org


--- 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

2007-08-06 Thread fxcoudert at gcc dot gnu dot org


--- 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

2007-08-06 Thread fxcoudert at gcc dot gnu dot org


--- 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

2007-08-06 Thread fxcoudert at gcc dot gnu dot org


--- 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)

2007-08-06 Thread pinskia at gcc dot gnu dot org


-- 

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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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'

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread pluto at agmk dot net


--- 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

2007-08-06 Thread aaw at gcc dot gnu dot org


--- 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

2007-08-06 Thread fxcoudert at gcc dot gnu dot org


--- 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

2007-08-06 Thread fxcoudert at gcc dot gnu dot org


--- 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

2007-08-06 Thread fxcoudert at gcc dot gnu dot org


--- 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

2007-08-06 Thread fxcoudert at gcc dot gnu dot org


--- 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

2007-08-06 Thread andreast at gcc dot gnu dot org


--- 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

2007-08-06 Thread burnus at gcc dot gnu dot org


--- 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

2007-08-06 Thread doko at gcc dot gnu dot org


--- 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

2007-08-06 Thread hjl at gcc dot gnu dot org


--- 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

2007-08-06 Thread burnus at gcc dot gnu dot org


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread roland at redhat dot com


--- 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

2007-08-06 Thread pluto at agmk dot net


--- 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

2007-08-06 Thread patchapp at dberlin dot org


--- 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

2007-08-06 Thread hjl at lucon dot org


--- 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

2007-08-06 Thread pluto at agmk dot net


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread kargl at gcc dot gnu dot org


--- 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

2007-08-06 Thread kargl at gcc dot gnu dot org


--- 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

2007-08-06 Thread michael dot a dot richmond at nasa dot gov
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

2007-08-06 Thread kargl at gcc dot gnu dot org


--- 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

2007-08-06 Thread kargl at gcc dot gnu dot org


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


-- 

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

2007-08-06 Thread bkoz at gcc dot gnu dot org


--- 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

2007-08-06 Thread fxcoudert at gcc dot gnu dot org


--- 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

2007-08-06 Thread dcb314 at hotmail dot com


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


-- 

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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread rodolfo at rodsoft dot org


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread fxcoudert at gcc dot gnu dot org


-- 

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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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)

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread rodolfo at rodsoft dot org
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)

2007-08-06 Thread rodolfo at rodsoft dot org
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

2007-08-06 Thread fxcoudert at gcc dot gnu dot org


-- 

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

2007-08-06 Thread hjl at lucon dot org


--- 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

2007-08-06 Thread aph at gcc dot gnu dot org


--- 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

2007-08-06 Thread drow at false dot org


--- 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

2007-08-06 Thread fxcoudert at gcc dot gnu dot org


--- 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

2007-08-06 Thread burnus at gcc dot gnu dot org


--- 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.

2007-08-06 Thread pluto at agmk dot net


--- 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

2007-08-06 Thread aph at gcc dot gnu dot org


--- 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

2007-08-06 Thread burnus at gcc dot gnu dot org


--- 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

2007-08-06 Thread sliwa at cft dot edu dot pl


--- 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.

2007-08-06 Thread pluto at agmk dot net


--- 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

2007-08-06 Thread aph at gcc dot gnu dot org


--- 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

2007-08-06 Thread sliwa at cft dot edu dot pl


--- 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.

2007-08-06 Thread pinskia at gmail dot com


--- 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.

2007-08-06 Thread Andrew Pinski
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.

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread burnus at gcc dot gnu dot org


--- 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.

2007-08-06 Thread pluto at agmk dot net
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

2007-08-06 Thread paolo dot bonzini at lu dot unisi dot ch


--- 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

2007-08-06 Thread pcarlini at suse dot de


--- 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

2007-08-06 Thread pinskia at gcc dot gnu dot org


--- 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

2007-08-06 Thread sliwa at cft dot edu dot pl


--- 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

2007-08-06 Thread sliwa at cft dot edu dot pl


--- 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

2007-08-06 Thread gerald at gcc dot gnu dot org


--- 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

2007-08-06 Thread sliwa at cft dot edu dot pl


--- 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

2007-08-06 Thread sliwa at cft dot edu dot pl
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

2007-08-06 Thread sliwa at cft dot edu dot pl


--- 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

2007-08-06 Thread sliwa at cft dot edu dot pl
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

2007-08-06 Thread fxcoudert at gcc dot gnu dot org


--- 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

2007-08-06 Thread fxcoudert at gcc dot gnu dot org


--- 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.

2007-08-06 Thread pcarlini at suse dot de


--- 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



  1   2   >