[Bug fortran/28923] New: Bad triplet interpretation in initialization

2006-09-01 Thread dominiq at lps dot ens dot fr
dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: gcc version 4.2.0 20060826 (experimental) GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28923

[Bug fortran/29312] New: Errors in subnormal calculation

2006-10-01 Thread dominiq at lps dot ens dot fr
Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: gcc version 4.2.0 20060930 GCC host triplet: PPC OSX

[Bug fortran/29312] Errors in subnormal calculation

2006-10-01 Thread dominiq at lps dot ens dot fr
--- Comment #1 from dominiq at lps dot ens dot fr 2006-10-01 23:05 --- Created an attachment (id=12367) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12367action=view) test of NEAREST, SPACING, and RRSPACING The reported errors come from the attached code. -- http

[Bug fortran/29410] New: [Optimization] bug with TRANSFER() and -O2

2006-10-10 Thread dominiq at lps dot ens dot fr
: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: 4.2.0 20061007 GCC target triplet: powerpc-apple-darwin7

[Bug fortran/29422] New: ICE with allocatable

2006-10-10 Thread dominiq at lps dot ens dot fr
Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: 4.2.0 20061009 GCC target triplet: x86_64-unknown-linux-gnu http

[Bug fortran/29422] ICE with allocatable

2006-10-11 Thread dominiq at lps dot ens dot fr
--- Comment #3 from dominiq at lps dot ens dot fr 2006-10-11 18:31 --- Subject: Re: ICE with allocatable Since I posted the patch, I had better take it unto myself! Be my guest!-) Dominique -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29422

[Bug fortran/29434] New: array bounds of allocatable components of derived types?

2006-10-11 Thread dominiq at lps dot ens dot fr
: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: 4.2.0 20061009 GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29434

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

2006-03-20 Thread dominiq at lps dot ens dot fr
: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26769

[Bug fortran/26976] New: Array assignment of elemental intrinsic functions does not check conformability

2006-04-01 Thread dominiq at lps dot ens dot fr
: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26976

[Bug fortran/27021] New: Problem with nearest(tiny(o),-1.0)/2.0

2006-04-04 Thread dominiq at lps dot ens dot fr
: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27021

[Bug rtl-optimization/29879] [4.3 Regression] ICE: verify_flow_info: loop_father but no loops

2006-11-19 Thread dominiq at lps dot ens dot fr
--- Comment #13 from dominiq at lps dot ens dot fr 2006-11-19 22:11 --- Applied to snapshot 4.3-20061118 on OSX 10.3, seems ok for me too, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29879

[Bug fortran/30400] New: ANY not accepted as mask in FORALL

2007-01-06 Thread dominiq at lps dot ens dot fr
Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org

[Bug fortran/30404] New: Wrong FORALL result

2007-01-08 Thread dominiq at lps dot ens dot fr
: Wrong FORALL result Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http

[Bug fortran/30406] New: ICE in LOGICAL(8) functions

2007-01-08 Thread dominiq at lps dot ens dot fr
dot org ReportedBy: dominiq at lps dot ens dot fr GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30406

[Bug fortran/30407] New: Compilation errors on valid code

2007-01-08 Thread dominiq at lps dot ens dot fr
dot ens dot fr GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30407

[Bug fortran/30406] ICE in LOGICAL(8) functions

2007-01-08 Thread dominiq at lps dot ens dot fr
--- Comment #2 from dominiq at lps dot ens dot fr 2007-01-08 13:42 --- Subject: Re: ICE in LOGICAL(8) functions Which version of gfortran did you use and which options? PPC OSX 10.3, version 4.3.0 20070105 Note that I did not see the ICE on x86_64-unknown-linux-gnu version 4.3.0

[Bug fortran/30406] ICE in LOGICAL(8) functions

2007-01-08 Thread dominiq at lps dot ens dot fr
--- Comment #5 from dominiq at lps dot ens dot fr 2007-01-08 19:05 --- Subject: Re: ICE in LOGICAL(8) functions Dominique, can you post the output file created with -fdump-tree-originial. Unfotunately I also got an ICE with -fdump-tree-original. The crash trace gives: 0 f951

[Bug fortran/30406] ICE in LOGICAL(8) functions

2007-01-08 Thread dominiq at lps dot ens dot fr
--- Comment #6 from dominiq at lps dot ens dot fr 2007-01-08 20:19 --- Subject: Re: ICE in LOGICAL(8) functions I got the same error with OSX 10.4, gcc version 4.2.0 20060617. I was wrong in my previous mail, -fdump-tree-original gives: f (l) { logical8 __result_f; __result_f

[Bug fortran/30406] ICE in LOGICAL(8) functions

2007-01-08 Thread dominiq at lps dot ens dot fr
--- Comment #8 from dominiq at lps dot ens dot fr 2007-01-08 20:49 --- Subject: Re: ICE in LOGICAL(8) functions Can you verify that OSX on PPC has logical(8)? I have tested: logical(8) :: l1, l2 l1 = .true. l2 = .false. print *, l1.neqv.l2, kind(l1.neqv.l2) end it returns T

[Bug fortran/30406] ICE in LOGICAL(8) functions

2007-01-09 Thread dominiq at lps dot ens dot fr
--- Comment #10 from dominiq at lps dot ens dot fr 2007-01-09 22:06 --- Subject: Re: ICE in LOGICAL(8) functions First, the crash report I have posted yesterday has nothing to do with this bug that is really an internal compiler error (caught within the compiler) and not a crash

[Bug fortran/30406] ICE in LOGICAL(8) functions

2007-01-09 Thread dominiq at lps dot ens dot fr
--- Comment #12 from dominiq at lps dot ens dot fr 2007-01-09 22:10 --- Subject: Re: ICE in LOGICAL(8) functions In C (and C++) Boolean types only have one size ... Too bad!-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30406

[Bug target/30406] ICE in LOGICAL(8) functions

2007-01-13 Thread dominiq at lps dot ens dot fr
--- Comment #24 from dominiq at lps dot ens dot fr 2007-01-13 17:09 --- I have applied the change to the latest snapshot (4.3.0 20070112) and the tests compile now without error on OSX 10.3.9. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30406

[Bug bootstrap/30511] False array bound check causes gcc failed to boostrap

2007-01-20 Thread dominiq at lps dot ens dot fr
--- Comment #6 from dominiq at lps dot ens dot fr 2007-01-20 13:27 --- On Mac OSX 10.3.9, after the same failure I have applied the patch of comment #1. Now the build fails with: /sw/src/fink.build/gcc4-4.3.0-20070120/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.3.0-20070120

[Bug libfortran/30518] New: failed to build libgfortran in gcc-4.3-20070119 on OSX 10.3.9

2007-01-20 Thread dominiq at lps dot ens dot fr
: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30518

[Bug libfortran/30518] failed to build libgfortran in gcc-4.3-20070119 on OSX 10.3.9

2007-01-20 Thread dominiq at lps dot ens dot fr
--- Comment #1 from dominiq at lps dot ens dot fr 2007-01-20 20:42 --- Created an attachment (id=12924) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12924action=view) preprocessed source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30518

[Bug libfortran/30518] failed to build libgfortran in gcc-4.3-20070119 on OSX 10.3.9

2007-01-20 Thread dominiq at lps dot ens dot fr
--- Comment #4 from dominiq at lps dot ens dot fr 2007-01-20 22:52 --- Subject: Re: failed to build libgfortran in gcc-4.3-20070119 on OSX 10.3.9 Thanks for the answers. I am not sure to fully understand them. Am I correct if I summarize them by saying that I should add a line

[Bug fortran/30617] New: recursive I/O hangs under OSX 10.3

2007-01-27 Thread dominiq at lps dot ens dot fr
dot ens dot fr GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617

[Bug fortran/30617] recursive I/O hangs under OSX 10.3

2007-01-27 Thread dominiq at lps dot ens dot fr
--- Comment #3 from dominiq at lps dot ens dot fr 2007-01-27 21:43 --- I believe recursive IO is undefined Probably, but the same code works with Target: x86_64-unknown-linux-gnu gcc version 4.3.0 20061231 (experimental) on a linux AMD64. -- http://gcc.gnu.org/bugzilla

[Bug libfortran/30617] recursive I/O hangs under OSX 10.3

2007-01-27 Thread dominiq at lps dot ens dot fr
--- Comment #6 from dominiq at lps dot ens dot fr 2007-01-27 22:01 --- Subject: Re: recursive I/O hangs under OSX 10.3 I agree this is probably platform specific. Can someone do the test on a Macintel? TIA -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617

[Bug libfortran/30617] recursive I/O hangs under OSX 10.3

2007-01-29 Thread dominiq at lps dot ens dot fr
--- Comment #9 from dominiq at lps dot ens dot fr 2007-01-29 14:13 --- Subject: Re: recursive I/O hangs under OSX 10.3 It hangs on a Intel iMac Thanks for the answer. So it hangs for the different flavor of OSX, but not for x86_64-unknown-linux-gnu (4.3.0 20061231) and i386-pc-linux

[Bug target/30406] ICE in LOGICAL(8) functions

2007-01-29 Thread dominiq at lps dot ens dot fr
--- Comment #25 from dominiq at lps dot ens dot fr 2007-01-29 15:13 --- What is the fate of the patch in comment #22? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30406

[Bug target/30406] ICE in LOGICAL(8) functions

2007-01-29 Thread dominiq at lps dot ens dot fr
--- Comment #28 from dominiq at lps dot ens dot fr 2007-01-29 20:47 --- Subject: Re: ICE in LOGICAL(8) functions I suppose Andrew should submit it for review by the PowerPC maintainers. If he doesn't have time, you could do it (unless he objects): Never do today what someone else

[Bug fortran/30654] Segmentation fault -O2 of file with deep nested loops

2007-01-31 Thread dominiq at lps dot ens dot fr
--- Comment #3 from dominiq at lps dot ens dot fr 2007-01-31 14:36 --- The variable 'ii1' does not seem initialized before line 34 where it is used. On my tests with the original code I got the output: 144454401.0 without optimization. With optimization, gfortran 4.3.0

[Bug libfortran/30617] recursive I/O hangs under OSX 10.3

2007-02-07 Thread dominiq at lps dot ens dot fr
--- Comment #13 from dominiq at lps dot ens dot fr 2007-02-07 09:24 --- Subject: Re: recursive I/O hangs under OSX 10.3 Section 9.5.3.7.1, paragarph 2, defines a child I/O statement as one that's occuring within a user-defined derived-type I/O function -- which is definitely

[Bug libfortran/30617] recursive I/O hangs under OSX

2007-02-07 Thread dominiq at lps dot ens dot fr
--- Comment #14 from dominiq at lps dot ens dot fr 2007-02-07 19:55 --- The test is known to fail on OSX 10.3 (gcc 4.3.0 20070202) and 10.4 (PPC with gcc 4.2.0 20070124 and MacIntel gcc unknown). When I have filled the PR I have forgotten to say that the same bug was present in http

[Bug libfortran/30617] recursive I/O hangs under OSX

2007-02-08 Thread dominiq at lps dot ens dot fr
--- Comment #16 from dominiq at lps dot ens dot fr 2007-02-08 08:45 --- Subject: Re: recursive I/O hangs under OSX Try : ... Or increase the size of string. I have increased the length to 20 and in both cases the executable (for an invalid code!-) works on OSX. I have also tried

[Bug libfortran/30617] recursive I/O hangs under OSX

2007-02-08 Thread dominiq at lps dot ens dot fr
--- Comment #18 from dominiq at lps dot ens dot fr 2007-02-08 10:03 --- Subject: Re: recursive I/O hangs under OSX gfortran.dg/intrinsic_actual_2.f90 fails on Linux too when linked with -fopenmp (or -lpthread, -fopenmp implies that), but that is fine, the testcase is IMHO not valid

[Bug libfortran/30617] recursive I/O hangs under OSX

2007-02-08 Thread dominiq at lps dot ens dot fr
--- Comment #19 from dominiq at lps dot ens dot fr 2007-02-08 12:06 --- The following invalid code: external fun real fun real a a = fun() ! print *, a write(10,*) fun(), a, 'try it', ' 1.23' end real function fun() print *, 'test' fun = 1.0 end gives a working executable when

[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)

2007-02-08 Thread dominiq at lps dot ens dot fr
--- Comment #11 from dominiq at lps dot ens dot fr 2007-02-08 21:25 --- I forgot that OS X is not supported by gcc 4.1 What do you mean? I have built gcc 4.1 on both OSX 10.3 an 10.4 several time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478

[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)

2007-02-08 Thread dominiq at lps dot ens dot fr
--- Comment #13 from dominiq at lps dot ens dot fr 2007-02-08 22:06 --- The build fails with errors of the following kind: /var/tmp//ccFScp77.s:3049:indirect jmp without `*' Sound familiar, aren't you speaking of MacIntel? I have done some testing on MacIntel with a prebuild

[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)

2007-02-08 Thread dominiq at lps dot ens dot fr
--- Comment #15 from dominiq at lps dot ens dot fr 2007-02-08 22:25 --- I think there is definitively a problem with the as provided on MacIntel. If you are interested I can dig my archives, I think I have some trace of the problem. Unfortunately I have only a limited access

[Bug target/30518] error from system header file

2007-02-08 Thread dominiq at lps dot ens dot fr
--- Comment #11 from dominiq at lps dot ens dot fr 2007-02-08 22:30 --- Subject: Re: error from system header file I cannot remember if I have given the appropriate feedback. I thought this bug was closed since I have probably done at least two builds since the bug appeared. If I

[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)

2007-02-09 Thread dominiq at lps dot ens dot fr
--- Comment #17 from dominiq at lps dot ens dot fr 2007-02-09 12:14 --- Thank you, but I think MacIntel is officially unsupported with 4.1. Do you have a pointer to this decision? TIA -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478

[Bug target/30406] ICE in LOGICAL(8) functions

2007-02-10 Thread dominiq at lps dot ens dot fr
--- Comment #30 from dominiq at lps dot ens dot fr 2007-02-10 22:12 --- Subject: Re: ICE in LOGICAL(8) functions Francois-Xavier, Thanks for the work. In order to improve future contributions, I have a few questions: (1) do you need a regtesting of the patch on 4.2 and OSX 10.4

[Bug target/30406] ICE in LOGICAL(8) functions

2007-02-10 Thread dominiq at lps dot ens dot fr
--- Comment #33 from dominiq at lps dot ens dot fr 2007-02-10 22:44 --- Subject: Re: ICE in LOGICAL(8) functions Thanks for the advice, I'll try to follow it next time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30406

[Bug libfortran/30617] recursive I/O hangs under OSX

2007-02-11 Thread dominiq at lps dot ens dot fr
--- Comment #22 from dominiq at lps dot ens dot fr 2007-02-12 07:37 --- Subject: Re: recursive I/O hangs under OSX PR fortran/30319 Thanks Paul ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617

[Bug fortran/30783] character(*), value produces SEGV at runtime

2007-02-13 Thread dominiq at lps dot ens dot fr
--- Comment #1 from dominiq at lps dot ens dot fr 2007-02-13 09:54 --- Compiling the test with xlf gives: pr30783.f90, line 6.12: 1513-061 (S) Actual argument attributes do not match those specified by an accessible explicit interface. pr30783.f90, line 11.14: 1516-181 (S) Objects

[Bug fortran/30793] Segfault on calling a function returning a pointer

2007-02-14 Thread dominiq at lps dot ens dot fr
--- Comment #3 from dominiq at lps dot ens dot fr 2007-02-14 19:00 --- For both test cases, xlf gives: ** class_mesh === End of Compilation 1 === ** class_field === End of Compilation 2 === pr30793.f90, line 127.5: 1515-039 (S) The target in the pointer assignment must have

[Bug fortran/30793] Segfault on calling a function returning a pointer

2007-02-14 Thread dominiq at lps dot ens dot fr
--- Comment #5 from dominiq at lps dot ens dot fr 2007-02-14 21:00 --- On AMD64, gfortran x86_64-unknown-linux-gnu, 4.3.0 20061231, gives: pr30793_1.f90:44.24: use class_scalar_field 1 Error: Name 'msh_' at (1) is an ambiguous reference to 'msh_' from module

[Bug fortran/30793] Segfault on calling a function returning a pointer

2007-02-14 Thread dominiq at lps dot ens dot fr
--- Comment #7 from dominiq at lps dot ens dot fr 2007-02-14 21:54 --- The following changes --- pr30793.f90 Wed Feb 14 19:50:03 2007 +++ pr30793_red.f90 Wed Feb 14 22:50:04 2007 @@ -33,7 +33,7 @@ end type field interface msh_ -module procedure msh_ +module procedure

[Bug fortran/25252] ICE on invalid code

2007-02-15 Thread dominiq at lps dot ens dot fr
--- Comment #6 from dominiq at lps dot ens dot fr 2007-02-15 21:43 --- I have the ICE pr25252.f90:6.46: MODULE PROCEDURE sreal, schar, sint = sreal 1 Error: Syntax error in MODULE PROCEDURE statement at (1) pr25252.f90:0

[Bug fortran/30874] incorrect error message for valid code

2007-02-20 Thread dominiq at lps dot ens dot fr
--- Comment #1 from dominiq at lps dot ens dot fr 2007-02-20 10:42 --- Works for me with: Target: powerpc-apple-darwin7, gcc version 4.3.0 20070216, plus patch for PR #30400. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30874

[Bug fortran/30881] incorrect error message for valid code

2007-02-20 Thread dominiq at lps dot ens dot fr
--- Comment #1 from dominiq at lps dot ens dot fr 2007-02-20 10:57 --- With Target: powerpc-apple-darwin7, gcc version 4.3.0 20070216, plus patch for PR #30400, I have: [address=437c pc=42343560] pr30881.f90:0: internal compiler error: Segmentation Fault Please submit a full bug

[Bug regression/30969] New: The polyhedron test 'fatigue.f90' is no longer working.

2007-02-26 Thread dominiq at lps dot ens dot fr
Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla

[Bug regression/30969] The polyhedron test 'fatigue.f90' is no longer working.

2007-02-26 Thread dominiq at lps dot ens dot fr
--- Comment #1 from dominiq at lps dot ens dot fr 2007-02-26 13:30 --- Created an attachment (id=13114) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13114action=view) this test works only without optimization -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30969

[Bug regression/30969] The polyhedron test 'fatigue.f90' is no longer working.

2007-02-26 Thread dominiq at lps dot ens dot fr
--- Comment #2 from dominiq at lps dot ens dot fr 2007-02-26 13:31 --- Created an attachment (id=13115) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13115action=view) test working with -O3 -ffast-math -funroll-loops -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30969

[Bug target/30969] The polyhedron test 'fatigue.f90' is no longer working.

2007-02-26 Thread dominiq at lps dot ens dot fr
--- Comment #4 from dominiq at lps dot ens dot fr 2007-02-26 17:50 --- Subject: Re: The polyhedron test 'fatigue.f90' is no longer working. Still works on x86_64, so it's a target issue. Nevertheless a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30969

[Bug middle-end/30969] [4.3 Regression] The polyhedron test 'fatigue.f90' is no longer working.

2007-02-27 Thread dominiq at lps dot ens dot fr
--- Comment #6 from dominiq at lps dot ens dot fr 2007-02-27 15:36 --- I don't know if this reduced test account for all the problem, but it exhibits at least one bug: module perdida_m implicit none contains subroutine perdida (dt, strain_tensor) real (kind = 8), intent

[Bug libfortran/30617] recursive I/O hangs under OSX

2007-03-03 Thread dominiq at lps dot ens dot fr
--- Comment #25 from dominiq at lps dot ens dot fr 2007-03-03 21:46 --- Is this actually now fixed or not? No, it is not. The commits are for the side effect of test case intrinsic_actual_2.f90 that has been fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30617

[Bug fortran/31120] New: ICE with integer_exponentiation_1.f90 and -ffast-math

2007-03-10 Thread dominiq at lps dot ens dot fr
: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC target triplet: powerpc-apple-darwin7 http

[Bug fortran/31120] ICE with integer_exponentiation_1.f90 and -ffast-math

2007-03-10 Thread dominiq at lps dot ens dot fr
--- Comment #1 from dominiq at lps dot ens dot fr 2007-03-10 10:25 --- FX Coudert reported that compiling the following code real :: a, b a = 3.0 b = a**(-4294967296_8) print *, b end segfaults on i686-linux (without -ffast-math). On OSX 10.3.9 I get Out of stack space. Try

[Bug middle-end/31030] [4.3 Regression] Segmentation fault with -O2

2007-03-10 Thread dominiq at lps dot ens dot fr
--- Comment #2 from dominiq at lps dot ens dot fr 2007-03-10 10:49 --- Confirmed on OSX 10.3.9 with snapshot 4.3.0 20070309. -- dominiq at lps dot ens dot fr changed: What|Removed |Added

[Bug target/30980] [4.3 Regression] Recent complex miscompilation

2007-03-11 Thread dominiq at lps dot ens dot fr
--- Comment #9 from dominiq at lps dot ens dot fr 2007-03-11 12:19 --- I confirm that the bug does not show with gcc. Is theis related to the following failures in the regtest? FAIL: gcc.dg/builtins-59.c scan-tree-dump __builtin_cexpi FAIL: gcc.dg/builtins-59.c scan-tree-dump

[Bug middle-end/31030] [4.3 Regression] Segmentation fault with -O2

2007-03-11 Thread dominiq at lps dot ens dot fr
--- Comment #3 from dominiq at lps dot ens dot fr 2007-03-11 12:58 --- The following reduced test case PROGRAM LINPK PARAMETER (N=2500,LDA=N+1) DOUBLE PRECISION a(LDA,N) , b(N) , x(N) a = 1.0 print *, 'before DSCAL' CALL DSCAL(N-1,1.0D0,A(2,1),1

[Bug middle-end/31030] [4.3 Regression] Segmentation fault with -O2

2007-03-11 Thread dominiq at lps dot ens dot fr
--- Comment #4 from dominiq at lps dot ens dot fr 2007-03-11 13:16 --- Note that the bug affect lapack/blas/{s,d}scal.f. Note also that in the *optimized* dumps of lapack/blas/{c,z}scal.f there are several: Invalid sum of incoming frequencies , should be cscal.f: ... Invalid

[Bug c/31161] New: __builtin_cexpi is broken on Darwin

2007-03-13 Thread dominiq at lps dot ens dot fr
Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161

[Bug target/31161] __builtin_cexpi is broken on Darwin

2007-03-13 Thread dominiq at lps dot ens dot fr
--- Comment #2 from dominiq at lps dot ens dot fr 2007-03-13 10:58 --- Subject: Re: __builtin_cexpi is broken on Darwin you should not use __builtin_cexpi if neither sincos nor cexp is available. Yes indeed, but an ICE is certainly not the best way to say it! Now I have tested

[Bug target/30980] [4.3 Regression] Recent complex miscompilation

2007-03-13 Thread dominiq at lps dot ens dot fr
--- Comment #10 from dominiq at lps dot ens dot fr 2007-03-13 12:56 --- The problem seems to come from a broken/unavailable __builtin_cexpi, see PR31161. My understanding is that __builtin_cexpi and __builtin_sincos are twin objects(?). Now I see in gcc/tree-ssa-math-opts.c

[Bug target/30980] [4.3 Regression] Recent complex miscompilation

2007-03-13 Thread dominiq at lps dot ens dot fr
--- Comment #13 from dominiq at lps dot ens dot fr 2007-03-13 14:48 --- The ICE you get in PR30969 shows that TARGET_C99_FUNCTIONS is _not_ set: Is there a way to test it once the building directory is gone? In gcc/config/rs6000/darwin.h I read: ... /* Old versions of Mac OS/Darwin

[Bug fortran/31120] ICE with integer_exponentiation_1.f90 and -ffast-math

2007-03-14 Thread dominiq at lps dot ens dot fr
--- Comment #4 from dominiq at lps dot ens dot fr 2007-03-14 13:58 --- Subject: Re: ICE with integer_exponentiation_1.f90 and -ffast-math And Dominique, I would appreciate if you could test the patch on ppc-darwin7. I'll do it tonight, but before could you test the following code

[Bug fortran/31120] ICE with integer_exponentiation_1.f90 and -ffast-math

2007-03-14 Thread dominiq at lps dot ens dot fr
--- Comment #6 from dominiq at lps dot ens dot fr 2007-03-14 14:27 --- Subject: Re: ICE with integer_exponentiation_1.f90 and -ffast-math On i686-linux, the unpatched compiler works OK without -ffast-math and segfaults with it. I am a little bit worried about that. As far as I know

[Bug fortran/31120] ICE with integer_exponentiation_1.f90 and -ffast-math

2007-03-15 Thread dominiq at lps dot ens dot fr
--- Comment #7 from dominiq at lps dot ens dot fr 2007-03-15 08:24 --- And Dominique, I would appreciate if you could test the patch on ppc-darwin7. So far all the tests passed. I am doing a full regtesting of gfortran, but I do not expect any new failure. Thanks for the fix

[Bug target/31161] __builtin_cexpi is broken on Darwin

2007-03-15 Thread dominiq at lps dot ens dot fr
--- Comment #5 from dominiq at lps dot ens dot fr 2007-03-15 08:34 --- Can you check if the attached patch gives a more reasonable error? I now get: failure_v2.c: In function 'main': failure_v2.c:15: sorry, unimplemented: no way to expand a call to 'cexpi' but would not it be more

[Bug fortran/31120] ICE with integer_exponentiation_1.f90 and -ffast-math

2007-03-15 Thread dominiq at lps dot ens dot fr
--- Comment #8 from dominiq at lps dot ens dot fr 2007-03-15 08:52 --- regtest results: ... Running /Users/dominiq/test/gcc-4.3-20070309/gcc/testsuite/gfortran.dg/dg.exp ... FAIL: gfortran.dg/large_real_kind_2.F90 -O0 execution test ... FAIL: gfortran.dg/large_real_kind_2.F90 -Os

[Bug target/31161] __builtin_cexpi is broken on Darwin

2007-03-15 Thread dominiq at lps dot ens dot fr
--- Comment #7 from dominiq at lps dot ens dot fr 2007-03-15 10:11 --- Subject: Re: __builtin_cexpi is broken on Darwin Yes, I'll restore 4.2.0 behavior here. Though maybe falling back to a function call to cexp would be more natural... I agree (see below). The Problem

[Bug target/31161] __builtin_cexpi is broken on Darwin

2007-03-15 Thread dominiq at lps dot ens dot fr
--- Comment #9 from dominiq at lps dot ens dot fr 2007-03-15 11:33 --- Subject: Re: __builtin_cexpi is broken on Darwin I have no idea why it is not working properly. Who could? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161

[Bug target/31161] __builtin_cexpi is broken on Darwin

2007-03-16 Thread dominiq at lps dot ens dot fr
--- Comment #13 from dominiq at lps dot ens dot fr 2007-03-16 09:27 --- Darwin people. Or at least someone with enough knowledge of ppc asm... Do they exist? If yes, are some living on planet earth? If yes, how do you catch them (at least their attention!-)? Fixed. (The ICE

[Bug target/31161] __builtin_cexpi is broken on Darwin

2007-03-16 Thread dominiq at lps dot ens dot fr
--- Comment #15 from dominiq at lps dot ens dot fr 2007-03-16 14:43 --- This bug was introduced by the CALL_EXPR changes: Good catch! Can you date the bug, i.e., was it introduced between snapshots 20070216 and 20070223? Thanks for the work. i'ld just like to see the darwin people

[Bug target/31161] __builtin_cexpi is broken on Darwin

2007-03-16 Thread dominiq at lps dot ens dot fr
--- Comment #16 from dominiq at lps dot ens dot fr 2007-03-17 00:22 --- As far as I can tell the problem is fixed, at least for Mac OSX 10.3. Thanks Richard for your patience. I have just noticed the following oddity with the code: #include math.h #include stdio.h int main

[Bug target/30980] [4.3 Regression] Recent complex miscompilation

2007-03-16 Thread dominiq at lps dot ens dot fr
--- Comment #14 from dominiq at lps dot ens dot fr 2007-03-17 00:26 --- Thanks to Richard Guenther, the bug seems to be fixed (hopefully in the 20070316 snapshot): see PR31161 for details. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980

[Bug middle-end/30969] [4.3 Regression] The polyhedron test 'fatigue.f90' is no longer working.

2007-03-16 Thread dominiq at lps dot ens dot fr
--- Comment #8 from dominiq at lps dot ens dot fr 2007-03-17 00:27 --- Thanks to Richard Guenther, the bug seems to be fixed (hopefully in the 20070316 snapshot): see PR31161 for details. I'll comment in another PR about the corresponding optimization (too late to do it tonight

[Bug target/31161] __builtin_cexpi is broken on Darwin

2007-03-17 Thread dominiq at lps dot ens dot fr
--- Comment #18 from dominiq at lps dot ens dot fr 2007-03-17 12:29 --- Subject: Re: __builtin_cexpi is broken on Darwin This is PR middle-end/30666. Patch for this problem is waiting for review. Thanks for the answer. I did not worried about the warn, but was only in the mode I

[Bug testsuite/31240] New: gcc/testsuite/gfortran.dg/pointer_intent_1.f90 failure on OSX

2007-03-17 Thread dominiq at lps dot ens dot fr
: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31240

[Bug middle-end/31249] New: pseudo-optimzation with sincos/cexpi

2007-03-17 Thread dominiq at lps dot ens dot fr
dot org ReportedBy: dominiq at lps dot ens dot fr GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249

[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi

2007-03-18 Thread dominiq at lps dot ens dot fr
--- Comment #2 from dominiq at lps dot ens dot fr 2007-03-18 10:20 --- Andrew, Thanks for the answer. Additional timings for AMD Opteron(tm) Processor 250, 2.4Ghz: Target: x86_64-unknown-linux-gnu ... gcc version 4.3.0 20061231 (experimental) [tocata] test/fortran gfc -O3 sincos.f90

[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi

2007-03-19 Thread dominiq at lps dot ens dot fr
--- Comment #3 from dominiq at lps dot ens dot fr 2007-03-19 09:28 --- BTW, did I miss an option to turn this optimization off? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249

[Bug fortran/31199] write with t1 format gives wrong output

2007-03-19 Thread dominiq at lps dot ens dot fr
--- Comment #6 from dominiq at lps dot ens dot fr 2007-03-19 12:15 --- Result by g95/ifort: You can probably add xlf to this list (should be checked on a recent version). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31199

[Bug fortran/31199] write with t1 format gives wrong output

2007-03-19 Thread dominiq at lps dot ens dot fr
--- Comment #7 from dominiq at lps dot ens dot fr 2007-03-19 12:18 --- You can probably add xlf to this list and Portland Group Fortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31199

[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi

2007-03-19 Thread dominiq at lps dot ens dot fr
--- Comment #5 from dominiq at lps dot ens dot fr 2007-03-19 12:43 --- There is no option to turn it off. But for !TARGET_C99_FUNCTIONS and !TARGET_HAS_SINCOS targets it's off. From my understanding of the thread http://gcc.gnu.org/ml/gcc/2007-03/msg00639.html if !TARGET_64BIT

[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi

2007-03-20 Thread dominiq at lps dot ens dot fr
--- Comment #8 from dominiq at lps dot ens dot fr 2007-03-20 13:57 --- The only reason why cexp is slow on PPC darwin is because the ABI is stupid. Complex float arguments are passed via the GPR and returned also the same way instead of via the FPRs. So you will get a transfer

[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi

2007-03-20 Thread dominiq at lps dot ens dot fr
--- Comment #9 from dominiq at lps dot ens dot fr 2007-03-20 14:03 --- I agree it's surprising to get user-visible effects with the TARGET_C99_FUNCTIONS difference between the frontends, but they are (supposed to) providing C99 runtime completion by their runtime libraries

[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi

2007-03-20 Thread dominiq at lps dot ens dot fr
--- Comment #11 from dominiq at lps dot ens dot fr 2007-03-20 14:57 --- Subject: Re: pseudo-optimzation with sincos/cexpi That sin+cos is practically sincos (so you get one for free). Just not every library exports that sincos. Does not this assume that it exists a real sincos(x

[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi

2007-03-20 Thread dominiq at lps dot ens dot fr
--- Comment #13 from dominiq at lps dot ens dot fr 2007-03-20 16:08 --- You can propose that we only enable sincos transformation if TARGET_HAS_SINCOS is set, I wouldn't necessarily object to that. (The targets I care for have a sincos) Sound reasonable: replacing: return

[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi

2007-03-21 Thread dominiq at lps dot ens dot fr
--- Comment #16 from dominiq at lps dot ens dot fr 2007-03-21 15:36 --- The recommended way is to post a message to gcc@gcc.gnu.org or [EMAIL PROTECTED] I'll follow your advice, but before I'ld like some feedback about what follows. I have applied the following patch --- gcc-4.3

[Bug middle-end/31249] pseudo-optimzation with sincos/cexpi

2007-03-21 Thread dominiq at lps dot ens dot fr
--- Comment #18 from dominiq at lps dot ens dot fr 2007-03-21 16:09 --- It would be nice to know whether darwin does not implement cexp in an optimal way ... I have forgotten to mention that I did some (quick) profiling: cexp seens trivially implemented. It calls sin, cos and exp

[Bug target/30980] [4.3 Regression] Recent complex miscompilation

2007-03-22 Thread dominiq at lps dot ens dot fr
--- Comment #15 from dominiq at lps dot ens dot fr 2007-03-22 16:22 --- Note that the drawback of the optimization replacing sin+cos by cexpi on PPC Darwin has been dissected in PR31249. In comment #16, I proposed a patch. Before applying it, it would be nice to test if the other

[Bug testsuite/31240] gfortran.dg/pointer_intent_1.f90 failure at -O0

2007-03-24 Thread dominiq at lps dot ens dot fr
--- Comment #1 from dominiq at lps dot ens dot fr 2007-03-24 22:28 --- xlf yields a bus error without optimization and -O, and abort with -O3. g95 gives the following errors: In file pointer_intent_1.f90:39 nullify(t%point) 1 Error: Cannot NULLIFY the INTENT

[Bug target/31394] cos() returns wrong value unless -O0 is used

2007-03-29 Thread dominiq at lps dot ens dot fr
--- Comment #2 from dominiq at lps dot ens dot fr 2007-03-29 18:50 --- This bug reminds me PR30980 and PR31161, though they were reported only for g++ and gfortran (they were fixed on 2007-03-16). Could you look at them to see if the bug you have reported is not a duplicate? If yes, you

[Bug target/31394] cos() returns wrong value unless -O0 is used

2007-03-30 Thread dominiq at lps dot ens dot fr
--- Comment #4 from dominiq at lps dot ens dot fr 2007-03-30 21:56 --- I suppose that makes it a duplicate of PR30980. It would have been better to check it directly before updating. PR30980 was related to g++ and gfortran and not gcc, so it seems that your platform (i386-pc

[Bug c/31429] New: Is anybody monitoring the daily regression tests on Darwin 8.5?

2007-04-02 Thread dominiq at lps dot ens dot fr
at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31429

  1   2   3   4   5   6   7   8   9   10   >