[Bug fortran/26017] allocate (a(1:-1)) should yield zero-sized array

2006-04-08 Thread tkoenig at gcc dot gnu dot org
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-04-08 21:47 --- Checking wether size is negative won't work as a complete fix for this. Consider the following example: $ cat a4.f90 program main real, allocatable:: a(:,:) allocate (a(1:-1,1:-1)) print *,size(a

[Bug fortran/25031] [4.1 only] Allocatable array can be reallocated.

2006-04-09 Thread tkoenig at gcc dot gnu dot org
--- Comment #8 from tkoenig at gcc dot gnu dot org 2006-04-09 09:00 --- Subject: Bug 25031 Author: tkoenig Date: Sun Apr 9 09:00:49 2006 New Revision: 112802 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112802 Log: 2006-04-09 Thomas Koenig <[EMAIL PROTECTED]&g

[Bug fortran/26017] allocate (a(1:-1)) should yield zero-sized array

2006-04-09 Thread tkoenig at gcc dot gnu dot org
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-04-09 19:37 --- Created an attachment (id=11228) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11228&action=view) patch This patch should do the trick. -- tkoenig at gcc dot gnu dot org changed:

[Bug fortran/26017] allocate (a(1:-1)) should yield zero-sized array

2006-04-09 Thread tkoenig at gcc dot gnu dot org
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-04-09 21:03 --- Created an attachment (id=11230) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11230&action=view) This one actually works :-) -- tkoenig at gcc dot gnu dot org changed: What|

[Bug fortran/27122] New: binary operator functions should require intent(in)

2006-04-11 Thread tkoenig at gcc dot gnu dot org
Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27122

[Bug fortran/26017] allocate (a(1:-1)) should yield zero-sized array

2006-04-16 Thread tkoenig at gcc dot gnu dot org
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-04-16 20:29 --- Subject: Bug 26017 Author: tkoenig Date: Sun Apr 16 20:29:24 2006 New Revision: 112988 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112988 Log: 2006-04-16 Thomas Koenig <[EMAIL PROTECTED]&g

[Bug fortran/26769] TRANSPOSE() requires _gfortran_transpose_i10 for REAL(10) arrays

2006-04-16 Thread tkoenig at gcc dot gnu dot org
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-04-16 21:15 --- Subject: Bug 26769 Author: tkoenig Date: Sun Apr 16 21:15:36 2006 New Revision: 112989 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112989 Log: 2006-04-16 Thomas Koenig <[EMAIL PROTECTED]&g

[Bug fortran/26769] Implement transpose() and reshape() for real instead of using integer

2006-04-16 Thread tkoenig at gcc dot gnu dot org
--- Comment #8 from tkoenig at gcc dot gnu dot org 2006-04-16 21:19 --- The error is now fixed on trunk and 4.1. What's left is to generate transpoe and reshape for the other real functions. Downgrading to enhancement and removing myself from this bug (for now). -- tkoenig a

[Bug fortran/25073] CASEs overlap

2006-04-17 Thread tkoenig at gcc dot gnu dot org
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-04-17 19:38 --- This is now fixed on mainline and 4.1: $ cat case.f90 program main logical :: l select case (l) case (.true.) case (.true.) end select end program main $ gfortran case.f90 In file case.f90:4 case

[Bug fortran/27320] New: ICE with -fdump-parse-tree after error

2006-04-25 Thread tkoenig at gcc dot gnu dot org
Keywords: ice-on-invalid-code Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27320

[Bug libfortran/26985] incorrect matmul result

2006-04-29 Thread tkoenig at gcc dot gnu dot org
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-04-29 16:30 --- Hi FX, would you care to replace rystride == ycount with rystride == xcount as a fix for this, independent of the matmul BLAS issue? I think this is definitely worth it, especially for 4.1. Pre-approved if you do

[Bug fortran/26017] allocate (a(1:-1)) should yield zero-sized array

2006-04-29 Thread tkoenig at gcc dot gnu dot org
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-04-29 21:02 --- Subject: Bug 26017 Author: tkoenig Date: Sat Apr 29 21:02:04 2006 New Revision: 113381 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113381 Log: 2006-04-29 Thomas Koenig <[EMAIL PROTECTED]&g

[Bug fortran/26017] allocate (a(1:-1)) should yield zero-sized array

2006-04-29 Thread tkoenig at gcc dot gnu dot org
--- Comment #8 from tkoenig at gcc dot gnu dot org 2006-04-29 21:05 --- Fixed on 4.1 and trunk. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/27470] New: [4.1 4.2 regression] wong memory allocator for derived types

2006-05-07 Thread tkoenig at gcc dot gnu dot org
Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gc

[Bug fortran/27470] [4.1/4.2 regression] wong memory allocator for derived types

2006-05-07 Thread tkoenig at gcc dot gnu dot org
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-05-07 19:36 --- (In reply to comment #1) > I wonder how related this is to PR 27411. As far as I can see, there's no relationship. To my eye, this looks like a stand-alone bug :-) Summary of what goes wrong: gfc_array_

[Bug fortran/27470] [4.1/4.2 regression] wrong memory allocator for derived types

2006-05-08 Thread tkoenig at gcc dot gnu dot org
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-05-08 21:06 --- Here's a test case that does not require transfer: TYPE foo INTEGER, DIMENSION(:), POINTER :: array END TYPE foo type(foo),allocatable,dimension(:) :: mol ALLOCATE (mol(1)) ALLOCATE (mol(1)%ar

[Bug fortran/27470] [4.1/4.2 regression] wrong memory allocator for derived types

2006-05-08 Thread tkoenig at gcc dot gnu dot org
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-05-08 21:59 --- Created an attachment (id=11415) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11415&action=view) patch This fixes the regression. It isn't pretty, because it would need to be changed a

[Bug fortran/27470] [4.1/4.2 regression] wrong memory allocator for derived types

2006-05-08 Thread tkoenig at gcc dot gnu dot org
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-05-08 22:11 --- Created an attachment (id=11416) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11416&action=view) better patch Forgot to initialize a variable in the earlier attempt. This one looks OK. -- tkoenig

[Bug fortran/25073] [missing testcase] CASEs overlap

2006-05-08 Thread tkoenig at gcc dot gnu dot org
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-05-08 22:15 --- > Thomas, can you give it a try since you designed the original patch? Actually, I didn't; I completely missed the original test case, checked this with my own (which didn't expose the error) an

[Bug fortran/20541] TR 15581: ALLOCATABLE components

2006-05-09 Thread tkoenig at gcc dot gnu dot org
--- Comment #8 from tkoenig at gcc dot gnu dot org 2006-05-09 21:27 --- Eric, when you work on this, watch out for the following test case: PROGRAM MAIN TYPE foo INTEGER, DIMENSION(:), ALLOCATABLE :: array END TYPE foo type(foo),pointer,dimension(:) :: mol ALLOCATE (mol

[Bug fortran/27470] [4.1/4.2 regression] wrong memory allocator for derived types

2006-05-10 Thread tkoenig at gcc dot gnu dot org
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-05-10 18:27 --- Subject: Bug 27470 Author: tkoenig Date: Wed May 10 18:26:51 2006 New Revision: 113680 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113680 Log: 2005-05-10 Thomas Koenig <[EMAIL PROTECTED]&g

[Bug bootstrap/27600] New: Bootstrap fails on cygwin

2006-05-14 Thread tkoenig at gcc dot gnu dot org
tstrap] Error 2 Output of nohup ./configure nohup make bootstrap nohup gcc -v will be attached. -- Summary: Bootstrap fails on cygwin Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: build Severity: normal Priorit

[Bug bootstrap/27600] Bootstrap fails on cygwin

2006-05-14 Thread tkoenig at gcc dot gnu dot org
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-05-14 09:42 --- Created an attachment (id=11459) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11459&action=view) output of configure; build; gcc -v -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27600

[Bug bootstrap/27600] Bootstrap fails on cygwin

2006-05-14 Thread tkoenig at gcc dot gnu dot org
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-05-14 09:43 --- Created an attachment (id=11460) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11460&action=view) config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27600

[Bug bootstrap/27600] Bootstrap fails on cygwin

2006-05-14 Thread tkoenig at gcc dot gnu dot org
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-05-14 09:44 --- Created an attachment (id=11461) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11461&action=view) config.status in main directory -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27600

[Bug bootstrap/27251] [4.2 Regression] undefined reference to `vec_assert_fail' with --disable-checking

2006-05-20 Thread tkoenig at gcc dot gnu dot org
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-05-20 19:26 --- Same error happens when building a native compiler with i686-pc-cygwin without --disable-checking, on an Athlon XP 2600, with a trunk as of a few minutes ago. Commands were: ../../gcc/trunk/configure --enable

[Bug bootstrap/27251] [4.2 Regression] undefined reference to `vec_assert_fail' with --disable-checking

2006-05-20 Thread tkoenig at gcc dot gnu dot org
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-05-20 19:38 --- (In reply to comment #2) > Same error happens when building a native compiler with i686-pc-cygwin > without --disable-checking, on an Athlon XP 2600, with a trunk as of > a few minutes ago. ... and on i686

[Bug web/27699] New: [bugzilla] CC should be transferred when closing a bug as duplicate

2006-05-21 Thread tkoenig at gcc dot gnu dot org
Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id

[Bug fortran/23151] print (buf, format), expression should be invalid

2006-05-23 Thread tkoenig at gcc dot gnu dot org
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-05-23 20:48 --- This patch looks as if it could do the job: Index: io.c === --- io.c(revision 113958) +++ io.c(working copy) @@ -2424,6 +2424,12

[Bug fortran/23151] print (buf, format), expression should be invalid

2006-05-23 Thread tkoenig at gcc dot gnu dot org
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-05-23 21:17 --- The previous patch was bogus. This one actually works: Index: io.c === --- io.c(revision 113958) +++ io.c(working copy) @@ -2424,6

[Bug fortran/23375] show location for runtime errors

2006-05-23 Thread tkoenig at gcc dot gnu dot org
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-05-23 21:41 --- (In reply to comment #3) > So in GCC 4.1.0, the only problem seems to be that _gfortran_runtime_error is > not printing the filename and the line number and the line number seems to be > the line numb

[Bug bootstrap/27763] New: add_referenced_var missing on bootstrap

2006-05-24 Thread tkoenig at gcc dot gnu dot org
Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27763

[Bug bootstrap/27763] add_referenced_var missing on bootstrap

2006-05-24 Thread tkoenig at gcc dot gnu dot org
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-05-24 19:47 --- I forget, this is i686-pc-linux-gnu, running Debian testing, on an Athlon XP 2600. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27763

[Bug bootstrap/27763] [4.2 regression] add_referenced_var missing on bootstrap

2006-05-24 Thread tkoenig at gcc dot gnu dot org
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 Summary|add_referenced_var missing |[4.2 regression

[Bug fortran/23375] show location for runtime errors

2006-05-24 Thread tkoenig at gcc dot gnu dot org
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-05-24 20:48 --- (In reply to comment #5) > So, how to make a patch for this: > Create a runtime_error_with_loc in gcc-4.1.0/libgfortran/runtime/error.c that > uses the a line number and filename. >

[Bug bootstrap/27763] [4.2 regression] add_referenced_var missing on bootstrap

2006-05-24 Thread tkoenig at gcc dot gnu dot org
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-05-24 22:18 --- The bug is with Path: . URL: svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 114050 Node Kind: directory Schedule: normal Last Changed Author: jsm28 Last

[Bug bootstrap/27763] [4.2 regression] add_referenced_var missing on bootstrap

2006-05-25 Thread tkoenig at gcc dot gnu dot org
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-05-25 11:09 --- This went away after an "svn update". The strange thing is that "svn diff" reported no differences before and after the upgrade. Cosmic rays, probably. Resolving as invalid. -- tkoenig at

[Bug fortran/23151] print (buf, format), expression should be invalid

2006-05-25 Thread tkoenig at gcc dot gnu dot org
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org

[Bug fortran/23151] print (buf, format), expression should be invalid

2006-05-26 Thread tkoenig at gcc dot gnu dot org
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-05-26 19:53 --- Subject: Bug 23151 Author: tkoenig Date: Fri May 26 19:53:18 2006 New Revision: 114138 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114138 Log: 2006-05-26 Thomas Koenig <[EMAIL PROTECTED]&g

[Bug fortran/27757] Problems with direct access io

2006-05-27 Thread tkoenig at gcc dot gnu dot org
--- Comment #10 from tkoenig at gcc dot gnu dot org 2006-05-27 19:10 --- This bug does not occur with g77, as this version of the test program shows: $ cat testdirect.f program testdirect implicit none integer a (100) integer i,j,k,ier real x

[Bug fortran/27470] [4.1 regression] wrong memory allocator for derived types

2006-05-27 Thread tkoenig at gcc dot gnu dot org
--- Comment #10 from tkoenig at gcc dot gnu dot org 2006-05-27 21:25 --- I applied the patch to the 4.1 branch, and I have a strange "regression": When running "make check-fortran", I get Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board

[Bug libfortran/27784] New: Comparison of strings with char(0)

2006-05-28 Thread tkoenig at gcc dot gnu dot org
Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org OtherBugsDependingO 19292 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27784

[Bug fortran/27470] [4.1 regression] wrong memory allocator for derived types

2006-05-28 Thread tkoenig at gcc dot gnu dot org
--- Comment #11 from tkoenig at gcc dot gnu dot org 2006-05-28 12:33 --- (In reply to comment #10) > > Not committing right now. Downloading a fresh version via svn cured that problem. I'd have commited the patch by now, but for some strange reason, I get "Authe

[Bug libfortran/27784] Comparison of strings with char(0)

2006-05-28 Thread tkoenig at gcc dot gnu dot org
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org

[Bug tree-optimization/22041] Reverse loop order for increased efficiency

2006-05-28 Thread tkoenig at gcc dot gnu dot org
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-05-28 14:10 --- (In reply to comment #3) > Dunno if tree loop reversal is already there, but Zdenek probably likes to > know > what bugs he is fixing... Loop reversal doesn't occur yet. gcc version 4.2.0 20060521

[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection

2006-05-28 Thread tkoenig at gcc dot gnu dot org
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-05-28 14:53 --- It's even worse: $ cat cmp.f program main external isgreater logical isgreater print *,"a" > "ä" print *,isgreater("a", "ä")

[Bug libfortran/27784] Comparison of strings with char(0)

2006-05-28 Thread tkoenig at gcc dot gnu dot org
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-05-28 16:05 --- (In reply to comment #1) > What about simply doing: > > Index: intrinsics/string_intrinsics.c > === > --- intrinsics/stri

[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection

2006-05-28 Thread tkoenig at gcc dot gnu dot org
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-05-28 16:10 --- (In reply to comment #3) > Created an attachment (id=11525) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11525&action=view) [edit] > Proposed patch > > I'm tempted to propose the atta

[Bug fortran/27470] [4.1 regression] wrong memory allocator for derived types

2006-05-28 Thread tkoenig at gcc dot gnu dot org
--- Comment #12 from tkoenig at gcc dot gnu dot org 2006-05-28 20:36 --- Subject: Bug 27470 Author: tkoenig Date: Sun May 28 20:35:53 2006 New Revision: 114176 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114176 Log: 2005-05-28 Thomas Koenig <[EMAIL PROTECTED]&g

[Bug fortran/27470] [4.1 regression] wrong memory allocator for derived types

2006-05-28 Thread tkoenig at gcc dot gnu dot org
--- Comment #13 from tkoenig at gcc dot gnu dot org 2006-05-28 20:37 --- Fixed on trunk and 4.1. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection

2006-05-30 Thread tkoenig at gcc dot gnu dot org
--- Comment #11 from tkoenig at gcc dot gnu dot org 2006-05-30 19:31 --- Hi FX, what about Index: arith.c === --- arith.c (revision 114111) +++ arith.c (working copy) @@ -1133,8 +1133,10 @@ gfc_compare_string

[Bug fortran/20884] subroutine accepted in operator interface

2006-05-31 Thread tkoenig at gcc dot gnu dot org
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-05-31 20:22 --- This is caught on mainline: $ gfortran qq.f90 In file qq.f90:3 MODULE PROCEDURE Is_Equal_To_Single 1 Error: User operator procedure 'is_equal_to_single' at (

[Bug fortran/23151] print (buf, format), expression should be invalid

2006-05-31 Thread tkoenig at gcc dot gnu dot org
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-05-31 20:51 --- Subject: Bug 23151 Author: tkoenig Date: Wed May 31 20:50:34 2006 New Revision: 114281 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114281 Log: 2006-05-31 Thomas Koenig <[EMAIL PROTECTED]&g

[Bug fortran/23151] print (buf, format), expression should be invalid

2006-05-31 Thread tkoenig at gcc dot gnu dot org
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-05-31 20:51 --- Fixed on trunk and 4.1. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/25073] CASEs overlap

2006-05-31 Thread tkoenig at gcc dot gnu dot org
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-05-31 21:10 --- This is a real bug, and not an issue of a missing test case. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added

[Bug tree-optimization/23452] Optimizing CONJG_EXPR (a) * a

2006-06-01 Thread tkoenig at gcc dot gnu dot org
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-06-01 19:13 --- (In reply to comment #3) > This is now fixed on mainline provided the user specifies -ffast-math. > There are some complications where imagpart(z*~z) can be non-zero, if > imagpart(z) is non-finite, such

[Bug fortran/27715] Extented ASCII characters lead to wrong "CASE" selection

2006-06-01 Thread tkoenig at gcc dot gnu dot org
--- Comment #13 from tkoenig at gcc dot gnu dot org 2006-06-01 19:24 --- Subject: Bug 27715 Author: tkoenig Date: Thu Jun 1 19:23:56 2006 New Revision: 114317 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114317 Log: 2006-06-01 Thomas Koenig <[EMAIL PROTECTED]&g

[Bug fortran/27866] Warn when casting, e.g. assigning a double precision to a real

2006-06-01 Thread tkoenig at gcc dot gnu dot org
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-06-01 21:09 --- (In reply to comment #0) > In the following program there is clearly a problem with the "r = d" > assignment. In most real programs such drastic case does not happen. However, > simple precision l

[Bug tree-optimization/22041] Reverse loop order for increased efficiency

2006-06-05 Thread tkoenig at gcc dot gnu dot org
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-06-05 21:30 --- (In reply to comment #5) > loop reversal was removed with the old loop optimizer; the tree level > loop reversal patch > (http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01851.html) was not > reviewed. Do

[Bug fortran/27866] Warn when casting, e.g. assigning a double precision to a real

2006-06-07 Thread tkoenig at gcc dot gnu dot org
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-06-07 19:32 --- Yes, this would be useful. Confirmed as an enhancement. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/27980] New: Wrong allocation for zero-sized function result

2006-06-09 Thread tkoenig at gcc dot gnu dot org
r zero-sized function result Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig a

[Bug fortran/27980] Wrong allocation for zero-sized function result

2006-06-09 Thread tkoenig at gcc dot gnu dot org
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org

[Bug fortran/27980] Wrong allocation for zero-sized function result

2006-06-12 Thread tkoenig at gcc dot gnu dot org
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-06-12 21:57 --- Created an attachment (id=11657) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11657&action=view) patch Here's a patch (regression-tested). I'm not 100% sure this is the most elega

[Bug fortran/27715] [4.1 only] Extented ASCII characters lead to wrong "CASE" selection

2006-06-16 Thread tkoenig at gcc dot gnu dot org
--- Comment #15 from tkoenig at gcc dot gnu dot org 2006-06-16 19:47 --- (In reply to comment #14) > Thomas, could you backport your patch to 4.1? (when you have some time, of > course) Hi FX, I have a few major RL concerns next week (a few critical presentations to give, ..

[Bug fortran/28384] ICE on non-existent COMMON block

2006-07-15 Thread tkoenig at gcc dot gnu dot org
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-07-15 13:40 --- > Index: gcc/fortran/trans-common.c > === > *** gcc/fortran/trans-common.c (revision 115409) > --- gcc/fortran/trans-common.c (

[Bug fortran/27980] [4.1 only] Wrong allocation for zero-sized function result

2006-07-15 Thread tkoenig at gcc dot gnu dot org
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-07-15 21:47 --- Created an attachment (id=11893) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11893&action=view) Patch for 4.1 Adapted patch for 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27980

[Bug fortran/27980] [4.1 only] Wrong allocation for zero-sized function result

2006-07-16 Thread tkoenig at gcc dot gnu dot org
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-07-16 10:12 --- Subject: Bug 27980 Author: tkoenig Date: Sun Jul 16 10:11:57 2006 New Revision: 115496 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115496 Log: 2006-07-16 Thomas Koenig <[EMAIL PROTECTED]&g

[Bug fortran/27980] [4.1 only] Wrong allocation for zero-sized function result

2006-07-16 Thread tkoenig at gcc dot gnu dot org
--- Comment #8 from tkoenig at gcc dot gnu dot org 2006-07-16 10:12 --- Fixed on mainline and 4.1. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/28397] New: Check format mismatches at compile time

2006-07-16 Thread tkoenig at gcc dot gnu dot org
dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28397

[Bug fortran/28399] New: Implement ftnchek-like warnings

2006-07-16 Thread tkoenig at gcc dot gnu dot org
Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28399

[Bug fortran/38135] FORALL gives wrong result

2008-11-15 Thread tkoenig at gcc dot gnu dot org
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-11-15 17:19 --- $ cat foo.f90 integer, parameter :: N = 3 integer A(N,N) A(1:N,1:N)=reshape(A(1:0,1),(/N,N/),reshape((/1/),(/N+1/),(/2/))) write(*,'(3i5)') A write(*,'(4i5)') reshape([1],[N+1],[0]) end $ gfo

[Bug fortran/38135] RESHAPE gives wrong result

2008-11-16 Thread tkoenig at gcc dot gnu dot org
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-11-16 09:04 --- Simplified test case (without the second reshape): The problem appears to be the empty SOURCE with the presence of PAD. $ cat bar.f90 program main integer, parameter :: N = 3 integer :: A(N,N) integer :: b(n

[Bug fortran/38135] RESHAPE gives wrong result

2008-11-16 Thread tkoenig at gcc dot gnu dot org
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-11-16 13:58 --- (In reply to comment #5) > > for (2), I'm puzzled. :( I'm onto it; the problems are in reshape.m4 / reshape_generic.c . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135

[Bug fortran/38135] RESHAPE gives wrong result

2008-11-16 Thread tkoenig at gcc dot gnu dot org
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-11-16 16:03 --- Created an attachment (id=16700) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16700&action=view) Patch for the library part Well, here's a patch for the library part. Apparently, nobody ev

[Bug fortran/38135] RESHAPE gives wrong result

2008-11-16 Thread tkoenig at gcc dot gnu dot org
--- Comment #11 from tkoenig at gcc dot gnu dot org 2008-11-16 20:38 --- Regression-test and full patch, including test cases, tomorrow. RL keeps interfering :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135

[Bug fortran/38135] RESHAPE gives wrong result

2008-11-18 Thread tkoenig at gcc dot gnu dot org
--- Comment #13 from tkoenig at gcc dot gnu dot org 2008-11-18 22:44 --- Subject: Bug 38135 Author: tkoenig Date: Tue Nov 18 22:43:05 2008 New Revision: 141982 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141982 Log: 2008-11-18 Thomas Koenig <[EMAIL PROTECTED]&g

[Bug fortran/38135] RESHAPE gives wrong result

2008-11-19 Thread tkoenig at gcc dot gnu dot org
--- Comment #14 from tkoenig at gcc dot gnu dot org 2008-11-19 19:33 --- The problem is fixed on trunk, I think we can close this after backporting. Mikael, if you think the problem you mentioned in comment #4 warrants its own PR, maybe you could open it. -- http://gcc.gnu.org

[Bug libfortran/38225] New: [4.4 regression] RESHAPE bounds with multi-dimensional SOURCE

2008-11-22 Thread tkoenig at gcc dot gnu dot org
: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38225

[Bug libfortran/38225] [4.4 regression] RESHAPE bounds with multi-dimensional SOURCE

2008-11-22 Thread tkoenig at gcc dot gnu dot org
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org

[Bug libfortran/38225] [4.4 regression] RESHAPE bounds with multi-dimensional SOURCE

2008-11-22 Thread tkoenig at gcc dot gnu dot org
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38225

[Bug libfortran/38225] [4.4 regression] RESHAPE bounds with multi-dimensional SOURCE

2008-11-22 Thread tkoenig at gcc dot gnu dot org
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-11-22 21:42 --- Subject: Bug 38225 Author: tkoenig Date: Sat Nov 22 21:41:27 2008 New Revision: 142125 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142125 Log: 2008-11-22 Thomas Koenig <[EMAIL PROTECTED]&g

[Bug libfortran/38225] [4.4 regression] RESHAPE bounds with multi-dimensional SOURCE

2008-11-22 Thread tkoenig at gcc dot gnu dot org
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-11-22 21:44 --- Fixed. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/27766] [meta] -fbounds-check related bugs

2008-11-22 Thread tkoenig at gcc dot gnu dot org
--- Comment #5 from tkoenig at gcc dot gnu dot org 2008-11-22 23:52 --- Current failures with bounds checking: FAIL: gfortran.dg/array_memset_2.f90 -O0 scan-tree-dump-times original "memset" 2 FAIL: gfortran.dg/array_memset_2.f90 -O1 scan-tree-dump-times original "

[Bug libfortran/38234] New: [4.4 Regression] In Reshape, SOURCE can be bigger than result

2008-11-23 Thread tkoenig at gcc dot gnu dot org
Version: 4.4.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org OtherBugsDependingO 27766

[Bug fortran/27766] [meta] -fbounds-check related bugs

2008-11-23 Thread tkoenig at gcc dot gnu dot org
--- Comment #7 from tkoenig at gcc dot gnu dot org 2008-11-23 08:54 --- (In reply to comment #6) > (2) The failure of gfortran.dg/bound_2.f90 comes from " Incorrect size in > SOURCE argument to RESHAPE intrinsic: is 9, should be 4". This is wrong, the > standard sa

[Bug libfortran/38234] [4.4 Regression] In Reshape, SOURCE can be bigger than result

2008-11-23 Thread tkoenig at gcc dot gnu dot org
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org

[Bug testsuite/38235] New: gfortran.dg/pr37243.f has undefined variables / bounds error

2008-11-23 Thread tkoenig at gcc dot gnu dot org
error Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org OtherBugsDep

[Bug fortran/38135] RESHAPE gives wrong result

2008-11-23 Thread tkoenig at gcc dot gnu dot org
--- Comment #16 from tkoenig at gcc dot gnu dot org 2008-11-23 15:10 --- Subject: Bug 38135 Author: tkoenig Date: Sun Nov 23 15:08:32 2008 New Revision: 142134 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142134 Log: 2008-11-23 Thomas Koenig <[EMAIL PROTECTED]&g

[Bug fortran/38135] RESHAPE gives wrong result

2008-11-23 Thread tkoenig at gcc dot gnu dot org
--- Comment #17 from tkoenig at gcc dot gnu dot org 2008-11-23 15:10 --- Fixed on 4.3. Closing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135

[Bug fortran/38135] RESHAPE gives wrong result

2008-11-23 Thread tkoenig at gcc dot gnu dot org
--- Comment #18 from tkoenig at gcc dot gnu dot org 2008-11-23 15:17 --- ... and now really closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added

[Bug libfortran/38234] [4.4 Regression] In Reshape, SOURCE can be bigger than result

2008-11-23 Thread tkoenig at gcc dot gnu dot org
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-11-23 19:27 --- Subject: Bug 38234 Author: tkoenig Date: Sun Nov 23 19:25:42 2008 New Revision: 142137 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142137 Log: 2008-11-23 Thomas Koenig <[EMAIL PROTECTED]&g

[Bug libfortran/38234] [4.4 Regression] In Reshape, SOURCE can be bigger than result

2008-11-23 Thread tkoenig at gcc dot gnu dot org
--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-11-23 19:32 --- Fixed. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/12742] Type alignment is lost if const is added to typedef

2008-12-03 Thread tkoenig at gcc dot gnu dot org
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-12-03 22:45 --- Test case still fails with fairly recent trunk. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/34780] Bootstrapping libstdc++-v3 failed

2008-12-03 Thread tkoenig at gcc dot gnu dot org
--- Comment #12 from tkoenig at gcc dot gnu dot org 2008-12-03 23:24 --- Still fails with today's trunk. Is this a regression? -- tkoenig at gcc dot gnu dot org changed: What|Removed |

[Bug fortran/37131] inline matmul for small matrix sizes

2008-12-04 Thread tkoenig at gcc dot gnu dot org
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-12-04 19:58 --- (In reply to comment #5) > For comparison with ifort ("loop was vectorized" in lines 40, 41, 43): > matmul =2.660166 s > subroutine without explicit interface: 0.000E+00 s

[Bug bootstrap/8677] "gcc -v" should report options used for bootstrap

2008-12-04 Thread tkoenig at gcc dot gnu dot org
--- Comment #9 from tkoenig at gcc dot gnu dot org 2008-12-04 20:18 --- Fixed a long time ago. Closing. $ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../gcc/trunk/configure --prefix=/home/ig25 --enable-languages=c,fortran --enable-maintainer-mode Thread

[Bug c/8960] Segfault with __attribute__ ((mode (...))) in start_function:5702

2008-12-06 Thread tkoenig at gcc dot gnu dot org
--- Comment #12 from tkoenig at gcc dot gnu dot org 2008-12-06 09:37 --- Still present with current trunk. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/27007] Missed optimization of comparison with 'limited range'

2008-12-06 Thread tkoenig at gcc dot gnu dot org
--- Comment #9 from tkoenig at gcc dot gnu dot org 2008-12-06 10:51 --- This is now fixed: $ cat foo.c int foo(unsigned char x) { return (x+1) != 0; } $ gcc -O3 -fdump-tree-optimized -S foo.c $ cat foo.s .file "foo.c" .text .p2align 4,,15

[Bug fortran/38425] I/O: POS= compile-time diagnostics

2008-12-06 Thread tkoenig at gcc dot gnu dot org
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-12-06 11:05 --- Confirmed. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC

[Bug fortran/38318] moving the allocation of temps out of loops.

2008-12-06 Thread tkoenig at gcc dot gnu dot org
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-12-06 20:25 --- This could also be useful when done in the middle-end, see PR 21046. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added

  1   2   3   4   5   6   7   8   9   10   >