--- Comment #2 from pault at gcc dot gnu dot org 2007-04-18 09:36 ---
(In reply to comment #1)
> Adding pault, as he's the likely culprit :)
>
Richard and Tobi,
I am a bit trapped right now, as chairman of a review meeting; I'll try to look
at it this evening.
On the face of it, chara
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-18 09:47
---
Subject: Bug 31286
Author: fxcoudert
Date: Wed Apr 18 09:47:28 2007
New Revision: 123944
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123944
Log:
PR libfortran/31286
PR libfortran/31296
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-18 09:47
---
Subject: Bug 31296
Author: fxcoudert
Date: Wed Apr 18 09:47:28 2007
New Revision: 123944
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123944
Log:
PR libfortran/31286
PR libfortran/31296
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-04-18 09:53
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-04-18 09:53
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-04-18 10:00 ---
Micha, this one should be catched by your conditional store patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from burnus at gcc dot gnu dot org 2007-04-18 10:18 ---
(In reply to comment #4)
Another thing which needs to be supported:
use mod, only: operator(foo) => operator(.op.), &
operator(bar) => operator(.op.), &
operator(op), &
--- Comment #3 from dorit at il dot ibm dot com 2007-04-18 10:18 ---
> Created dump file using -fdump-tree-vect-details
thanks. So I don't understand why we expect to version for 3 different
data-references, since there are only 2 in the loop that is vectorized. But
then I wonder why we
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-18 10:21 ---
(In reply to comment #1)
>
> if (any (Up ("AbCdEfGhIjKlM") .ne. (/"ABCDEFGHIJKLM"/))) call abort ()
> contains
> Character (len=20) Function Up (string)
>
>
> It looks like it's comparing a CHARACTER*20 (= Up's
--- Comment #4 from pault at gcc dot gnu dot org 2007-04-18 10:44 ---
(In reply to comment #2)
Changing the comparison to
if (Up ("AbCdEfGhIjKlM") .ne. "ABCDEFGHIJKLM") call abort ()
gets rid of the problem.
I have clearly exposed something extremely unpleasant in ANY or the compar
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-18 10:54
---
Hey, this has turned into an ICE on today's trunk. Cool, it's gonna be easier
to work on! :)
As I pointed out in http://gcc.gnu.org/ml/fortran/2007-04/msg00295.html, this
makes it a potential double regression, w
--- Comment #7 from dfranke at gcc dot gnu dot org 2007-04-18 11:14 ---
See also: PR30471, PR30613 and PR31400 :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31604
14 ) and z( 17 ) and LocalTimeStep( 17 )
reading again x and z in foo
x ( 17 ) and z( 8 ) and LocalTimeStep( 0 )
STOP OK
--
Summary: backspace intrinsic is not working on an unformatted
file
Product: gcc
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-04-18 12:45 ---
Subject: Bug 21463
Author: rguenth
Date: Wed Apr 18 12:45:09 2007
New Revision: 123946
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123946
Log:
2007-04-18 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-04-18 12:45
---
Subject: Bug 19431
Author: rguenth
Date: Wed Apr 18 12:45:09 2007
New Revision: 123946
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123946
Log:
2007-04-18 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-04-18 12:46
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-04-18 12:48
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #20 from pluto at agmk dot net 2007-04-18 13:02 ---
(In reply to comment #19)
> Fixed.
>
will it be backported to 4.2?
it improves perf. of big stl-based apps.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19431
The following error occured when I try to run the c program after compiling
with gcc
Segmentation fault
The C program is as follows
//testr.c
#include
main () {
float rd[9331200];
int jd = 5;
printf("jd = %d\n",jd);
}
//Compile command
gcc testr.c
The output of the c
If an array of a derived type is declared and one component is set to zero then
all the components are set to zero. The following program illustrates the
problem:
program test_assign
type my_type
integer :: a
integer :: b
end type my_type
type(my_type), dimension(1) :: mine
m
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-04-18 14:09 ---
Strange, indeed.
Can confirm this behaviour for 4.3 (20070417), neither 4.1.1 nor 4.2 (20070417)
exhibit the problem.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |
--- Comment #7 from anirkko at insel dot ch 2007-04-18 14:24 ---
(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?
>
The bootstrap works fine with all flags equal to '-O2'
Sti
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-04-18 14:25 ---
$> cat pr31620.f90
program test_assign
type my_type
integer :: a
integer :: b
end type my_type
type(my_type), dimension(1) :: mine! note that MINE is an array
mine%b=4
mine%a=1
print *,
--- Comment #13 from arcangelpip at hotmail dot com 2007-04-18 14:34
---
I'm going to try again since it seems my last post was just ignored.
The test case works fine on 4.2 but it still occurs under some circumstances.
As I stated in my previous post Gettext is where it dies but I can
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2007-04-18 14:35
---
> The bootstrap works fine with all flags equal to '-O2'
Great, thanks for the confirmation.
> Still worrysome, because somewhere in the installation instructions, it is
> recommended to bootstrap the compiler w
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-04-18 14:45
---
Ha, sure not ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19431
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-04-18 14:51
---
output.tar attachment should go to pr31409
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31207
--- Comment #10 from zingale at gmail dot com 2007-04-18 14:58 ---
Thanks for the help. I'll put together a tarball and pass it to you privately
as instructed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31551
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-04-18 15:01
---
hmm, I will investigate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31618
$ echo 'int main(){return 0;}' >tmp.c && gcc -xc++ tmp.c
/tmp/ccGESvie.o:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
libstdc++'s configure missdetects in this way the -Wl,--gc-sections
support in the linker.
(...)
configure:8405: checking for ld that supports -Wl,--gc-sections
--- Comment #2 from ian at airs dot com 2007-04-18 15:14 ---
Yes, the warning is happening because gcc relies on undefined signed overflow
when assuming that it will execute the loop at least once. Of course when
using -fwrapv the loop should not be executed at all when num > INT_MAX -
--- Comment #1 from schwab at suse dot de 2007-04-18 15:24 ---
Either use g++ or link with -lstdc++.
--
schwab at suse dot de changed:
What|Removed |Added
Sta
--- Comment #2 from schwab at suse dot de 2007-04-18 15:27 ---
Reopening since it's a problem with libstdc++ configure.
--
schwab at suse dot de changed:
What|Removed |Added
--
--- Comment #3 from tobi at gcc dot gnu dot org 2007-04-18 15:56 ---
(In reply to comment #2)
> 2053 need_interface_mapping = ((sym->ts.type == BT_CHARACTER
My patch from r123924 (the one about magic numbers) touched
gfc_add_interface_mapping. Can you try reverting it, otherwise I
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-18 15:59 ---
You just happen to overflow the stack. The stack limit is too low for your
array. This is not a GCC bug, either use limit or ulimit depening on the shell
you use to figure out the stack limit.
--
pinskia at gcc
CONTEXT:
- GCC version: 4.3.0.
- Front end: gcj.
- Operating System: Linux Debian, kernel 2.6.17-2-686.
- Hardware: CPU Intel Pentium 4 Xeon, 3 GHz, 16 KB cache L1, 2 MB cache L2.
RAM: 1 GB.
There is a segment violation error when compiling the following code:
public class Fail
{
public stat
The following code (simplified for clarity), does not compile on GCC versions
past 4.0, but compiles fine with gcc-3.3 and other non-GCC compilers (MSVC++,
etc):
#include
template
class VectorBase
{
protected:
char * memory;
public:
VectorBase()
{
memo
Problem description
===
Function names are mangled in gprof output. Such name mangling in gprof
output only occurs when compiling with g++ under 64 bit modes
Compiler output
===
The name HelloWorld is mangled.
Flat profile:
Each sample counts as 0.01 seconds.
no time
--- Comment #9 from dfranke at gcc dot gnu dot org 2007-04-18 17:06 ---
What happend to this? I can't find the patch in the tracker anymore, but
there's no indication in the ChangeLog(s) that is was applied. The ML
discussion went somewhat off track after a while. Any indication to pursu
--- Comment #14 from dfranke at gcc dot gnu dot org 2007-04-18 17:26
---
As FX kindly provided a patch in comment #13, are there any plans to pick it up
and commit it?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Test gcc.dg/dfp/convert-dfp-fold.c started failing on powerpc-linux with this
patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=123719
r123719 | dnovillo | 2007-04-11 16:14:06 + (Wed, 11 Apr 2007)
The test, which is compiled with -O, converts between decimal and binary
floating types, c
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2007-04-18 17:57
---
(In reply to comment #14)
> As FX kindly provided a patch in comment #13, are there any plans to pick it
> up
> and commit it?
As I said, I'm not sure it's the best thing to do, because it gives a warning
for s
--- Comment #1 from tromey at gcc dot gnu dot org 2007-04-18 18:12 ---
Are you sure you are using gcj 4.3?
I see a SEGV with 4.1 and 4.2. But with 4.3 I see an error:
opsy. gcj -C Fail.java
Fail.java:5: error: Cannot invoke toString() on the primitive type long
r=(a-b).toStri
--- Comment #2 from Catherine dot M dot Moroney at jpl dot nasa dot gov
2007-04-18 18:16 ---
Subject: Re: Inability to read ascii text with generic 'f' format
read(10,*) doesn't work. I have access to two other compilers
(SGI and Portland Group) and both of them accepted the
read(10,
--- Comment #10 from burnus at gcc dot gnu dot org 2007-04-18 18:19 ---
> What happend to this? I can't find the patch in the tracker anymore, but
> there's no indication in the ChangeLog(s) that is was applied.
The last patch was applied, i.e. gfortran uses now _gfortran_ prefixes to f
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-18 18:19 ---
This is not a GCC bug, please read: http://gcc.gnu.org/gcc-3.4/changes.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||missed-optimization
Summary|decimal float comparison|[
--- Comment #3 from echristo at apple dot com 2007-04-18 18:44 ---
As a note, this is due to the make install bit of libgcc when putting things
back into the gcc build dir we set $(slibdir) to null and then the darwin
install name ends up being set to $(slibdir)/libgcc_s.1.dylib which en
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-04-18 18:47
---
*** This bug has been marked as a duplicate of 30471 ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-04-18 18:47
---
*** Bug 31604 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-04-18 18:48
---
I certainly agree that we should have an option to ask the driver to link
libgfortran statically.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from jb at gcc dot gnu dot org 2007-04-18 19:05 ---
(In reply to comment #10)
> > What happend to this? I can't find the patch in the tracker anymore, but
> > there's no indication in the ChangeLog(s) that is was applied.
>
> The last patch was applied, i.e. gfortran use
--- Comment #16 from dfranke at gcc dot gnu dot org 2007-04-18 19:15
---
FX, which version of glibc do you have installed?
I applied your patch to an otherwise unpatched tree and do not get any
warnings, neither at compile time of libgfortran(*) nor while compiling/linking
a binary (a
--- Comment #22 from pluto at agmk dot net 2007-04-18 19:18 ---
(In reply to comment #21)
> Ha, sure not ;)
>
and wait another years for 4.3 release. it sux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19431
The following code should tell us we have an out-of-bounds access at runtime:
$ cat a.f90
subroutine foo(a)
integer a(*), i
i = 0
a(i) = 42
end subroutine foo
program test
integer x(42)
call foo(x)
end program test
$ gfortran a.f90 -fbounds-check && ./a.out
--
Summary: -b
--
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 #17 from fxcoudert at gcc dot gnu dot org 2007-04-18 19:21
---
(In reply to comment #16)
> nor while compiling/linking
> a binary (a hello-world in this case, glibc-2.5)
It happens when you compile and link statically a Fortran code that uses
GETLOG().
I've ended up convin
--- Comment #23 from pinskia at gcc dot gnu dot org 2007-04-18 19:21
---
(In reply to comment #22)
> and wait another years for 4.3 release. it sux.
GCC 4.3 is the one of the few compilers to do this optimization.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19431
--- Comment #4 from tobi at gcc dot gnu dot org 2007-04-18 19:29 ---
The segfault is present with r123923, so it's not my patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
--- Comment #18 from dfranke at gcc dot gnu dot org 2007-04-18 19:39
---
> It happens when you compile and link statically a Fortran code
> that uses GETLOG().
Confirmed. But if and only if it uses GETLOG(). Thus, it's not too bad. From
comment #13, I assumed that the warning is issue
Testcase is extracted from Wine.
/home/marcus/projects/gcc/BIN/bin/gcc -m32 -fPIC -O2 -o reg reg.i
./reg
Segmentation fault
(I did not try the i586 version of the compiler.)
Looking at the disassembly the stdcall function is compiled as:
foo:
pushl %ebp
movl%esp, %ebp
--- Comment #1 from marcus at jet dot franken dot de 2007-04-18 19:44
---
Created an attachment (id=13389)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13389&action=view)
reg.i
gcc -fPIC -O2 -m32 reg.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31628
--- Comment #2 from marcus at jet dot franken dot de 2007-04-18 19:45
---
i bisected gcc to find the regression and it was apparently introduced by
revision 123146.
2007-03-22 Richard Henderson <[EMAIL PROTECTED]>
* config/i386/i386.c (ix86_function_regparm): Early exit for 6
--- Comment #3 from marcus at jet dot franken dot de 2007-04-18 19:46
---
the interesting part is that the declaration is just slightly incompatible
with the actual definition. If I remove the prototype the problem goes away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31628
--- Comment #12 from jb at gcc dot gnu dot org 2007-04-18 19:49 ---
> The reason why the patch is in limbo (besides me being busy with real life :(
> )
> is that while it worked fine under Linux, it turned out that it doesn't work
> on
> many other platforms since on those platforms th
--- Comment #17 from hjl at lucon dot org 2007-04-18 20:00 ---
Testcase in comment #16 failed on ia32, x86-64 and ia64 with -O3. 051t.alias3
dump looks strange. 102t.final_cleanup dump is:
[EMAIL PROTECTED] bad]$ cat x.cc.102t.final_cleanup
;; Function int main() (main)
int main() ()
--- Comment #18 from hjl at lucon dot org 2007-04-18 20:02 ---
(In reply to comment #17)
> Testcase in comment #16 failed on ia32, x86-64 and ia64 with -O3. 051t.alias3
> dump looks strange. 102t.final_cleanup dump is:
>
> [EMAIL PROTECTED] bad]$ cat x.cc.102t.final_cleanup
>
> ;; Func
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-18 20:04 ---
gprof is not part of GCC, it is part of binutils.
The problem is that gprof is not stripping out the dot part of the symbol.
Report this to the binutils folks.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-04-18 20:16 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
I prefer (but the Fortran standard does NOT require) that all module entities
used outside the module should be explicitly declared
PUBLIC.
g95 has an option -fmodule-private such that
g95 -fmodule-private for the code
module foo_mod
implicit none
! public :: i
integer :: i
end module foo_mod
p
--- Comment #3 from kargl at gcc dot gnu dot org 2007-04-18 21:03 ---
(In reply to comment #2)
> Subject: Re: Inability to read ascii text with generic 'f' format
>
> read(10,*) doesn't work. I have access to two other compilers
> (SGI and Portland Group) and both of them accepted the
--- Comment #6 from mueller at gcc dot gnu dot org 2007-04-18 21:09 ---
Subject: Bug 31227
Author: mueller
Date: Wed Apr 18 21:09:21 2007
New Revision: 123958
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123958
Log:
2007-04-18 Dirk Mueller <[EMAIL PROTECTED]>
PR diag
--- Comment #7 from mueller at gcc dot gnu dot org 2007-04-18 21:10 ---
Fixed in 4.3.
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-04-18 21:38 ---
13207 return integer_zerop (int_const_binop (TRUNC_MOD_EXPR,
13208top, bottom, 0));
(gdb) p debug_generic_expr (top)
4
$1 = void
(gdb) p debug_generic_expr (bo
--- Comment #19 from hjl at lucon dot org 2007-04-18 21:47 ---
For
for(unsigned i=0;i<1;i++) result += a.begin[i];
x.ii.004t.gimple looks like
const int * D.2454;
long unsigned int D.2455;
long unsigned int D.2456;
const int * D.2457;
const int * D.2458;
D.2455 = (long u
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-04-18 21:57 ---
1469tree size_of_op0_points_to = TYPE_SIZE_UNIT (TREE_TYPE
(op0type));
and size_of_op0_points_to is a zero constant.
Reduced testcase:
struct polynomial {
~polynomial ();
};
void spline_rep1
--- Comment #20 from hjl at lucon dot org 2007-04-18 22:11 ---
build_array_ref calls
return build_indirect_ref (cp_build_binary_op (PLUS_EXPR, ar, ind),
"array indexing");
with ar as pointer and ind as integer. cp_build_binary_op turns ind into
pointe
--- Comment #5 from rth at gcc dot gnu dot org 2007-04-18 22:14 ---
Reproducing the problem requires -maccumulate-outgoing-args,
as implied by i686 tuning.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
-
The following code (original code courtesy of Mike Zingale, reduced by yours
truly) gives an ICE with current mainline:
module box_module
type box
integer :: m = 0
end type box
end module box_module
module sort_box_module
contains
subroutine heapsort_box(cmp)
interface
subro
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-04-18 22:40
---
It's a 4.3 regression, because it compiles with 4.2 (although I haven't looked
at the generated code).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-04-18 22:47
---
Code in comment #19 is perfectly correct. I can reproduce the difference with
the attached testcase and -O -fstrict-aliasing -finline-functions.
-fno-strict-aliasing fixes it.
--
http://gcc.gnu.org/bugzilla/
--- Comment #22 from rguenth at gcc dot gnu dot org 2007-04-18 22:56
---
And this is the bug:
# SFT.0_29 = V_MAY_DEF ;
# SFT.1_30 = V_MAY_DEF ;
this_7->elems[0] = 1;
the following is supposed to read it.
# VUSE ;
D.2148_18 = *D.2147_17;
it's interesting that
Points-
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-04-18 22:59
---
(In reply to comment #13)
> The tree stuff is hard, btw. Still trying :-)
Tree stuff? Do we generate inline code?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-04-18 23:01
---
Closing this. We should really open new PRs for different intrinsics, when we
have code and perf measurements.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #5 from tobi at gcc dot gnu dot org 2007-04-18 23:56 ---
For the record, the problem Richard is pointing out is in the body of the
function Up, namely in the expression for MERGE, probably caused by TRANSFER.
Nevertheless, the accepts-invalid is also an embarassing problem (
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-19 02:27 ---
*** Bug 31622 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-19 02:27 ---
This is the same problem as referenced in PR 27442.
*** This bug has been marked as a duplicate of 27442 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-04-19 03:47
---
Confirming. g77 does not do it right either. :)
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-04-19 04:05
---
It looks like this platform has different error messages for a given error. I
suggest that this test case be either marked as expected to fail for this
platform or we could delete the test case altogether.
Anot
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-04-19 04:49 ---
(In reply to comment #3)
> It looks like this platform has different error messages for a given error.
Yes that's correct. I ran open_errors.exe under the solaris truss command and
saw this:
open64("./", O_RDWR|O_CR
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-04-19 05:11 ---
(In reply to comment #3)
> But then I wonder why we don't see the same failure on ia64?
Because the failing part of the testcase is only done on ilp32 targets:
! { dg-final { scan-tree-dump-times "Alignment of access
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-19 06:32 ---
(In reply to comment #1)
Move use sort_box_module up to module level and it compiles fine. This is yet
another derived type association regression that I would swear is identical to
one of the testcases:)
It's mine.
--- Comment #5 from dorit at il dot ibm dot com 2007-04-19 07:27 ---
(In reply to comment #4)
> (In reply to comment #3)
> > But then I wonder why we don't see the same failure on ia64?
> Because the failing part of the testcase is only done on ilp32 targets:
> ! { dg-final { scan-tree-d
--- Comment #6 from burnus at gcc dot gnu dot org 2007-04-19 07:44 ---
> Nevertheless, the accepts-invalid is also an embarassing problem (unless we
> collectively misunderstand Fortran rules :)
Well, we do.
if (any (Up ("AbCdEfGhIjKlM") .ne. (/"ABCDEFGHIJKLM"/))) stop 'ERROR'
compile
95 matches
Mail list logo