--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-04-16 07:00
---
Do really have a SuperSPARC? If no, remove the -mcpu=supersparc option, it is
totally untested these days. If so, I'd suggest to stick with a 3.x compiler
on this presumably old machine.
--
ebotcazou at gcc
--- Comment #3 from fxcoudert at gmail dot com 2007-04-16 07:03 ---
Subject: Re: ICE at -O1 -fipa-pta
PS, I will fix this sometime after we have LTO.
Until then, -fipa-pta is not worth it.
Can it be made an undocumented option, then, for the time being?
Because it's still an ICE
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-16 07:43 ---
The trunk gives:
t.cc: In member function 'void CT::DoSomething(int) [with CT::Inner I = c,
T = double]':
t.cc:32: instantiated from here
t.cc:24: error: incomplete type 'Cdouble::Dispatcherc, 1' used in nested
These tests all start to fail after the fix for PR 31361 was committed to SVN.
FAILing tests test SSE intrinsics by:
--quote--
/* Test that the intrinsics compile with optimization. All of them are
defined as inline functions in mmintrin.h that reference the proper
builtin functions.
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-16 07:56 ---
Reduced testcase:
struct Industry {
unsigned char produced_cargo[2];
};
unsigned int a = (((unsigned long)reinterpret_castconst volatile
charIndustry*)(char*)8)-produced_cargo[0]))) - 8);
--
pinskia at gcc
--- Comment #1 from ubizjak at gmail dot com 2007-04-16 08:02 ---
Proposed patch to macroize these functions in emmintrin.h
(http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00096.html).
Please note that some other intrinsic functions, such as _mm_shuffle_ps() are
defined as macro as well
--- Comment #4 from anirkko at insel dot ch 2007-04-16 09:15 ---
(In reply to comment #2)
Can you try without setting the CFLAGS, etc. because what might be happening
is
the base compiler miscompiling the new compiler?
Tried something slightly different: because this happened in
--- Comment #5 from anirkko at insel dot ch 2007-04-16 09:21 ---
(In reply to comment #3)
Do really have a SuperSPARC? If no, remove the -mcpu=supersparc option, it is
totally untested these days. If so, I'd suggest to stick with a 3.x compiler
on this presumably old machine.
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-04-16 09:59
---
Will try next without -O3 and other flags to see if one of these generate the
error.
Most likely I'd say. I happen to regularly bootstrap GCC 4.1.x with GCC 3.4.3
and the default options on Solaris 2.5.1 and
The documentation mentions:
-falign-functions=n
-fno-align-functions and -falign-functions=1 are equivalent and mean that
functions will not be aligned.
and
If n is not specified or is zero, use a machine-dependent default.
But, it seems the semantics are reversed when using
If we recompile a file that outputs the same .mod files, they shouldn't get
updated: it makes dependency analysis useless and probably makes parallel
compiling (make -jN) less efficient.
$ cat a.f90
module foo
integer, parameter :: bar = 42
end module foo
$ gfortran -c a.f90
$ stat foo.mod |
gcc has various -M options to create Makefile dependencies for automatic
dependency tracking, which is very nice for compilation of large projects.
gfortran should be able to do the same. Here are examples with g95:
$ cat a.f90
module foo
integer, parameter :: bar = 42
end module foo
$ g95 -M
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #2 from numerical dot simulation at web dot de 2007-04-16
10:31 ---
The compiler at
http://www.comeaucomputing.com/tryitout/
has absolutely no problems with the code.
M$-VC8 says:
error C2754: 'CT::Dispatcherc,dummy' : a partial specialization cannot have
a dependent
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-04-16 11:02 ---
FX, +5 karma for this proposal :)
How about USE association? For example
$ cat a.f90
module a
[...]
end module
$ cat b.f90
[...]
USE a
[...]
$ gfortran -M a.f90
a.o a.mod: a.f90
$ gfortran -M b.f90
b.o: a.mod
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-16 11:06
---
(In reply to comment #1)
How about USE association?
That's also part of the plan.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
--- Comment #1 from krebbel at gcc dot gnu dot org 2007-04-16 12:38 ---
The same happens on s390 and s390x. The constant Default_Bit_Order is definded
in system.ads:
-- Other System-Dependent Declarations
type Bit_Order is (High_Order_First, Low_Order_First);
--- Comment #1 from tobi at gcc dot gnu dot org 2007-04-16 13:28 ---
An easy solution that I thought about implementing in the past would be to put
a checksum into the file header. First the module file would be written to a
temporary file. This file would be checksummed and only
--- Comment #2 from tobi at gcc dot gnu dot org 2007-04-16 13:31 ---
Given your other PR, another solution that comes to mind is to include the
filename and modification date of the source file in the module file, and to
compare these before writing a module file. This would be more
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-04-16 13:33
---
Better than my current idea for that, which was to compare line after line the
old and new files. What cheap hash function should we use? MD5?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31587
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-04-16 13:34
---
(In reply to comment #2)
include the
filename and modification date of the source file in the module file, and to
compare these before writing a module file
I think that defeats the purpose: if the source
--- Comment #5 from tobi at gcc dot gnu dot org 2007-04-16 13:35 ---
(In reply to comment #3)
Better than my current idea for that, which was to compare line after line the
old and new files. What cheap hash function should we use? MD5?
Probably, as it is included in libiberty, and
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #1 from tobi at gcc dot gnu dot org 2007-04-16 13:39 ---
I think the simplest fix is rewording the error message to, say,
No interface found for operator .notfound. with operand types REAL(4)/REAL(4)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31580
--- Comment #2 from tobi at gcc dot gnu dot org 2007-04-16 13:52 ---
Issuing a warning would be a good thing, INTEGER*8 value may be greater than
longest possible CHARACTER on your architecture, maybe even a runtime error in
the second case. I hope you're not suggesting that we devise
Dorit Nuzman supplied a patch to correct failures reported when running
testsuite. These failures have been reported in all results posted to
gcc-testsuite. The patch adds target specifiers, correcting the associated
FAIL reports on my system, for the cases
pr30771.c
vect-iv-4.c
vect-iv-9.c
--- Comment #3 from tobi at gcc dot gnu dot org 2007-04-16 14:14 ---
Reduced testcase:
real, dimension(1), parameter :: r=1.0
real, dimension(1) :: s=RESHAPE(r,(/1/))
IF (ANY(s.NE.1.0)) CALL ABORT()
END
--
tobi at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pluto at agmk dot net 2007-04-16 14:16 ---
/home/pawels/toolchain41-src/gcc-4.1.2/builddir/gcc/xgcc -v
Using built-in specs.
Target: sparc64-sun-solaris2.9
Configured with: ../configure --target=sparc64-sun-solaris2.9
--- Comment #4 from pluto at agmk dot net 2007-04-16 14:16 ---
Created an attachment (id=13370)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13370action=view)
config.logs
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31536
--- Comment #1 from tprince at computer dot org 2007-04-16 14:18 ---
Created an attachment (id=13371)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13371action=view)
adds target qualifiers to files in gcc.dg/vect/
patch supplied to me by Dorit Nuzman. It changes ia64 reports from
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|tobi at gcc dot gnu dot org |unassigned at gcc dot gnu
|
--- Comment #2 from hjl at gcc dot gnu dot org 2007-04-16 14:49 ---
Subject: Bug 31582
Author: hjl
Date: Mon Apr 16 14:49:14 2007
New Revision: 123866
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123866
Log:
2007-04-16 H.J. Lu [EMAIL PROTECTED]
PR target/31582
--- Comment #3 from hjl at gcc dot gnu dot org 2007-04-16 14:58 ---
Subject: Bug 31582
Author: hjl
Date: Mon Apr 16 14:57:37 2007
New Revision: 123868
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123868
Log:
2007-04-16 H.J. Lu [EMAIL PROTECTED]
* Backport from
--- Comment #7 from patchapp at dberlin dot org 2007-04-16 15:00 ---
Subject: Bug number PR 31144
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-04/msg00985.html
--
--- Comment #4 from hjl at gcc dot gnu dot org 2007-04-16 15:04 ---
Subject: Bug 31582
Author: hjl
Date: Mon Apr 16 15:04:30 2007
New Revision: 123872
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123872
Log:
2007-04-16 H.J. Lu [EMAIL PROTECTED]
* Backport from
--- Comment #5 from hjl at lucon dot org 2007-04-16 15:06 ---
I checked the patch into 4.1/4.2/4.3.
--
hjl at lucon dot org changed:
What|Removed |Added
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-16 15:28 ---
What about
include foo.f90
and
#include bar.f90
(g95 handles both)
And what about
include z.f90
where z.f90 is foo/z.f90 and is found via
gfortran -Jfoo ?
(g95 does not handle this and writes: b.o b.mod: b.F90
--- Comment #2 from tobi at gcc dot gnu dot org 2007-04-16 15:37 ---
I'll have a look.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org
--- Comment #63 from mkuvyrkov at gcc dot gnu dot org 2007-04-16 16:04
---
Subject: Bug 28071
Author: mkuvyrkov
Date: Mon Apr 16 16:04:18 2007
New Revision: 123874
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123874
Log:
PR middle-end/28071
* sched-int.h (struct deps): Split
--- Comment #64 from mkuvyrkov at gcc dot gnu dot org 2007-04-16 16:07
---
(In reply to comment #63)
Scheduler memory hungryness should be fixed by the above commit.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
--- Comment #4 from dberlin at gcc dot gnu dot org 2007-04-16 16:55 ---
Subject: Re: ICE at -O1 -fipa-pta
On 16 Apr 2007 06:03:45 -, fxcoudert at gmail dot com
[EMAIL PROTECTED] wrote:
--- Comment #3 from fxcoudert at gmail dot com 2007-04-16 07:03 ---
Subject: Re:
--- Comment #16 from hubicka at gcc dot gnu dot org 2007-04-16 17:07
---
Subject: Bug 27869
Author: hubicka
Date: Mon Apr 16 17:07:19 2007
New Revision: 123876
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123876
Log:
PR target/27869
* config/i386/sse.md
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-04-16 17:47 ---
Can you unset CFLAGS and try again? I bet 4.1.2 is being miss compiled at
least looking at the logs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31536
--- Comment #13 from spark at gcc dot gnu dot org 2007-04-16 17:49 ---
Subject: Bug 29365
Author: spark
Date: Mon Apr 16 17:49:02 2007
New Revision: 123879
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123879
Log:
gcc/ChangeLog:
2007-04-16 Seongbae Park [EMAIL PROTECTED]
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #15 from bangerth at dealii dot org 2007-04-16 19:02 ---
True. This has been fixed since 4.0.x.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #4 from dberlin at gcc dot gnu dot org 2007-04-16 19:14 ---
Doing cast motion actually causes about 25 *more* failures in the vectorizer
testsuite.
I'm closing this as won't fix since it seems there was no other reason to do
this.
--
dberlin at gcc dot gnu dot org
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-04-16 19:24
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31576
See the bit of code below dealing with the initialization of array contents
with
the ubound results called on another array. If the module statements plus
the write(*,*) statements are both commented out, then this bit of code
compiles. However, if either (a) this code is made into a module, or
--- Comment #4 from steven at gcc dot gnu dot org 2007-04-16 19:40 ---
This is not yet fixed.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Last
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-04-16 20:05 ---
Tested gfortran v4.1.1, v4.2 and a recent svn checkout, none of them reported
an ICE. Which version do you use?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31591
--- Comment #2 from Catherine dot M dot Moroney at jpl dot nasa dot gov
2007-04-16 20:07 ---
Subject: Re: internal compiler error on array initialization statement using
'ubound'
[EMAIL PROTECTED]:/data/svn_workspace/cmm/sieglind/PGE/L2TC/
StandardProcessing/AZM/make [69]gfortran
--- Comment #5 from bonzini at gnu dot org 2007-04-16 20:10 ---
What about a patch like this?
Index: macro.c
===
--- macro.c (revision 123691)
+++ macro.c (working copy)
@@ -499,9 +499,15 @@ paste_all_tokens
--- Comment #2 from bonzini at gnu dot org 2007-04-16 20:11 ---
Created an attachment (id=13372)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13372action=view)
patch to fix part of the bug
This patch seems to fix the preprocessor side of the bug. However there are
problems later
--- Comment #3 from bonzini at gnu dot org 2007-04-16 20:24 ---
Created an attachment (id=13373)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13373action=view)
patch to fix part of the bug
By fixing the preprocessor part better, we can fix the bug completely.
However, I don't
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-04-16 20:42 ---
Ups, misread your report. After uncommenting the WRITE, all tested compilers
crash.
$ gfortran -v
gcc version 4.3.0 20070331
Backtrace:
Breakpoint 1, fancy_abort (file=0x86e4fec
The following is invalid and detected as such, however, the error message needs
improvement
PROGRAM Test_ceres
implicit none
real, dimension(10) :: TCg_coef
integer, parameter, dimension(1) ::
TCg_bband_coef_ranks = X()
contains
function X()
integer, dimension(1) :: X
X
--- Comment #4 from burnus at gcc dot gnu dot org 2007-04-16 21:14 ---
The assert is trans-array.c's gfc_conv_array_initializer
switch (expr-expr_type)
{
...
default:
gcc_unreachable ();
Here, expr-expr_type is EXPR_FUNCTION.
By the way, the scalar version, i.e.
Compare this:
$ cat count.f90
program main
implicit none
integer, parameter :: value = 747
integer :: p1, p2, p3, p4
integer :: i
do i=1, 10
do p1 = 1, value-2
do p2 = p1 + 1, value - p1
do p3 = p2 + 1, value - p1 - p2
p4 = value - p1 - p2 - p3
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-04-16 22:54 ---
*** Bug 31593 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-16 22:54 ---
This is not suprising as it is a dup of bug 20165 anyways.
*** This bug has been marked as a duplicate of 20165 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from tkoenig at gcc dot gnu dot org 2007-04-16 23:03 ---
(In reply to comment #1)
This is not suprising as it is a dup of bug 20165 anyways.
*** This bug has been marked as a duplicate of 20165 ***
Only one part.
The other part is that we don't mark the variables in
The attached fortran code (a smaller section cut and paste from original) was
generated by a custom preprocessor. The code very much seems to be valid
fortran 77, though its has some weird tab spacings; It compiles (and executes)
fine with pgf90 and ifort-8.x. The compile time error is as below
--- Comment #1 from deji_aking at yahoo dot ca 2007-04-16 23:07 ---
Created an attachment (id=13374)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13374action=view)
testcase (cut and paste from original)
I can provide the whole file if necessary
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-16 23:12 ---
call output (p1, p2, p3, p4)
That still clobbers p1, p2, p3, and p4 as they are passed by reference so is it
really undefined code if output changes the values for the do loop?
--
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-04-16 23:15
---
OK, I've researched the libiberty md5.c interface a bit and here's the first
half of a patch :) It computes the MD5 sum of the module file (except the
first 3 lines) and it writes it at the top, like this:
--- Comment #1 from patchapp at dberlin dot org 2007-04-16 23:30 ---
Subject: Bug number PR c++/31517
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-04/msg01041.html
--
--- Comment #5 from mmitchel at gcc dot gnu dot org 2007-04-17 00:28
---
Subject: Bug 31513
Author: mmitchel
Date: Tue Apr 17 00:28:21 2007
New Revision: 123902
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123902
Log:
PR c++/31513
* call.c
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-04-17 00:34
---
Fixed in 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from tobi at gcc dot gnu dot org 2007-04-17 01:09 ---
Subject: Bug 31144
Author: tobi
Date: Tue Apr 17 01:09:34 2007
New Revision: 123904
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123904
Log:
PR fortran/31144
fortran/
* decl.c (gfc_sym_mangled_identifier):
--- Comment #9 from tobi at gcc dot gnu dot org 2007-04-17 01:12 ---
Fixed.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from tobi at gcc dot gnu dot org 2007-04-17 01:14 ---
(In reply to comment #3)
call output (p1, p2, p3, p4)
That still clobbers p1, p2, p3, and p4 as they are passed by reference so is
it
really undefined code if output changes the values for the do
--- Comment #2 from tobi at gcc dot gnu dot org 2007-04-17 01:20 ---
Your lines are too wide, hoping that bugzilla will not mess up the formatting
I'll quote an example:
1 2 3 4 5 6 7
--- Comment #8 from vingocheng at 126 dot com 2007-04-17 06:16 ---
The problem still exist. My working environment is :
GCC : gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
GMP : the latest release version (gmp4.1)
During compiling, the error will occur.
But I fount if I
--- Comment #10 from ian at gcc dot gnu dot org 2007-04-17 06:33 ---
Subject: Bug 31522
Author: ian
Date: Tue Apr 17 06:33:38 2007
New Revision: 123908
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123908
Log:
./:
PR tree-optimization/31522
* tree-vrp.c
--- Comment #30 from dberlin at gcc dot gnu dot org 2007-04-17 06:53
---
Is this really still broken in mainline?
At least as of Richard's last update, it wasn't
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19580
81 matches
Mail list logo
