fxcoudert at gcc dot gnu dot org wrote:
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-11-28 07:08
---
No, it's in fact easier than that. We shouldn't come into us_read for this
file, which is formatted! Probably a bad default flag is set.
I think you are right. I have bee
--- Comment #5 from jvdelisle at verizon dot net 2005-11-28 08:09 ---
Subject: Re: namelist read from non-opened file
fxcoudert at gcc dot gnu dot org wrote:
> --- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-11-28 07:08
> ---
> No, it's in fact easier than that. We
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2005-11-28 09:27
---
Fixed on 4.1 and 4.2. Won't be fixed on 4.0.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
Hello,
gcc version: gcc-3.3.3
system type: IBM AIX 64bit 5.3.3
I am trying to compile a 64bit version of gcc-3.4.2 using gcc-3.3.3 (32bit) on
a PowerPC AIX 5.3 64bit.
My configure:
export OBJECT_MODE=64
export CC=gcc
export CXX=g++
export CFLAGS="-O2 -maix64 -g -mminimal-toc"
export CXXFLAGS=
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2005-11-28 09:33
---
Well, at least that one should be easy (L without a width specifier is an
extension, and the width is then taken to be 1). I'm on it.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from gdr at gcc dot gnu dot org 2005-11-28 10:19 ---
(In reply to comment #4)
> Subject: Re: [3.4 only] [hppa] 'bus error' at runtime while passing a special
> struct to a C++ member function
>
> > Are you working on this? It lools like the bug has been there for a whil
--- Comment #3 from gdr at gcc dot gnu dot org 2005-11-28 10:20 ---
Postpone until 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|3.4
--- Comment #7 from gdr at gcc dot gnu dot org 2005-11-28 10:22 ---
Postpone until 3.4.6
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|3.4
--- Comment #3 from nathan at gcc dot gnu dot org 2005-11-28 10:34 ---
Subject: Bug 21166
Author: nathan
Date: Mon Nov 28 10:34:30 2005
New Revision: 107599
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107599
Log:
.:
PR c++/21166
* c-decl.c (finish_struct): On
--- Comment #2 from bonzini at gnu dot org 2005-11-28 10:53 ---
Created an attachment (id=10352)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10352&action=view)
patch to fix the bug
Kaz, can you please test this patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25115
The following program should occur an error since the same named
entity from different modules cannot be referenced.
However, I compiled successfully, and got output "foo".
I think it is wrong behavior.
module m_foo
contains
subroutine foo
print *, "foo"
end subroutine
end module
module
--- Comment #3 from kkojima at gcc dot gnu dot org 2005-11-28 12:30 ---
It fixes the ICE and produces better codes. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25115
--- Comment #5 from johannes at sipsolutions dot net 2005-11-28 12:39
---
Hm. I didn't use -lrtgcc, that must have been a typo/copy&paste error, I
definitely used -lrt
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25118
--- Comment #2 from zerocool at modemsoft dot it 2005-11-28 12:48 ---
Subject: GCC Java not compile
> --- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-25
> 20:14 ---
> Can you attach the source you are trying to compile?
I have taken the source of the gcc 4.02 from
--- Comment #4 from giovannibajo at libero dot it 2005-11-28 13:01 ---
Out of curiosity, can you show the code before and after Paolo's patches?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25115
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-28 13:19 ---
Confirmed, IFC gives:
fortcom: Error: The same named entity from different modules and/or program
units cannot be referenced. [FOO]
in file (null), line 0, column 0
compilation aborted for t.f90 (code 1)
--
pi
--- Comment #5 from kkojima at gcc dot gnu dot org 2005-11-28 13:33 ---
Argh. I've got the results other way around.
Before patch:
--
.global foo
.type foo, @function
foo:
mov.l r12,@-r15
mov.l r14,@-r15
mov r15,r14
mov.l .L16
--- Comment #34 from marc dot waeckerlin at siemens dot com 2005-11-28
13:37 ---
What now? What happened since July? There's not even a new trouble report open
asking for "__GCC_PTHREADS__".
What can I as library writer now do, if I want to know whether or not I am in
valid multithread
--- Comment #35 from aoliva at gcc dot gnu dot org 2005-11-28 14:15 ---
Created an attachment (id=10353)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10353&action=view)
Pach that fixes the weakref behavior on darwin
Could someone with access to the affected OS please try this pat
gcc.c-torture/compile/20050303-1.c fails when it is compiled with
m68k-elf-gcc -m5200 -O0.
gcc.c-torture/compile/20050303-1.c:10: error: insn does not satisfy its
constraints:
(insn 17 45 18 (set (mem/c/i:SI (plus:SI (reg/f:SI 14 %a6)
(const_int -12 [0xfff4])) [0 toread+0 S4 A1
The following code:
struct S
{ int x[3]; };
void f()
{ S s = {1,2,3};}
With -Wmissing-braces (which is implied by -Wall, among others) gives:
warning: missing braces around initializer for 'int [3]'
In the specific case where a struct contains only a single array, adding the
extra braces doesn
Consider
double
foo (unsigned int a)
{
return a;
}
int
main (void)
{
return 0;
}
When I compile and link this like so
m68k-elf-gcc -Wl,-T,sim.ld -o test test.c
I get
undefined reference to `__floatunsidf'
Inspection of m5200/libgcc.a reveals that it does not contain __floatunsidf.
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-28 14:52 ---
I don't see why the warning is not useful at all, in fact I rather have the C++
standard fix their wording of TR1's array.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-28 14:49 ---
I think this is a 4.2 regression cause by JSM's patch, could you check to see
if this is a regression?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25138
--- Comment #2 from chris at bubblescope dot net 2005-11-28 15:17 ---
Thats an option too, but I thought I'd see about gcc's opinion first, as I
expected a much faster reply than I would get from the C++ steering committee
:)
I find the warning helpful for constructs like:
struct S { i
--- Comment #6 from krebbel at gcc dot gnu dot org 2005-11-28 15:34 ---
Created an attachment (id=10354)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10354&action=view)
Testcase which failes on S/390 64bit with -O2
This testcase is reduced from gengtype-lex.c. Due to this bug it
--- Comment #6 from toon at moene dot indiv dot nluug dot nl 2005-11-28
15:36 ---
> I think you are right. I have been putting in debug statements all over and
> find that we are asking the wrong length of reads, 8 characters, instead of 1
> in the failing case. I will get back to th
--- Comment #36 from dir at lanl dot gov 2005-11-28 15:53 ---
With patches "gcc41-pr24991.patch" (I also need this to build on LINUX) and
"gcc-weakref-darwin.patch" (the patch gcc/ChangeLog failed, but that did not
matter) installed and a fresh down load of gfortran, gfortran builds and
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2005-11-28 15:59
---
I think the following patch (no time yet to regtest it, and won't have time
soon, please feel free to test it) fixes it:
Index: transfer.c
===
--- t
--- Comment #1 from rearnsha at gcc dot gnu dot org 2005-11-28 16:03
---
Confirmed. This appears to be a bug in noce_try_abs, which is substituting an
abs() expansion into the RTL, but the substitution clobbers a hard register
that is live (the condition code register).
--
rearnsha
--- Comment #3 from gdr at integrable-solutions dot net 2005-11-28 16:15
---
Subject: Re: Warning "missing braces around initializer" causing problems with
tr1::array
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| I don't see why the warning is not useful at all, in f
--- Comment #4 from gdr at integrable-solutions dot net 2005-11-28 16:18
---
Subject: Re: New: Warning "missing braces around initializer" causing
problems with tr1::array
"chris at bubblescope dot net" <[EMAIL PROTECTED]> writes:
| The following code:
|
| struct S
| { int x[3]; };
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-28 16:28 ---
fold_range_test is wrong, around fold-const.c:4635
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23518
--- Comment #5 from chris at bubblescope dot net 2005-11-28 16:28 ---
I'll make a report. Don't worry, I'm clear on the difference between tr1::array
and a C array, I just wanted to check that we agree this should produce a
warning (in which case I will go through the tr1::array testcase
--- Comment #6 from chris at bubblescope dot net 2005-11-28 16:33 ---
Actually, is a report really approriate? Writing array = {1,2,3} is
perfectly valid C++, just warned about with -Wmissing-braces
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25137
--- Comment #6 from johannes at sipsolutions dot net 2005-11-28 16:34
---
And shouldn't a header/library mismatch segfault without optimisation as well?
But if it works for you I'll just see with the next gcc version I get.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25118
I have been getting this error on one of my programs that does extremely
complex I/O operations for a few months now, but I have been unable to isolate
it. I finally got the same error message from a program that generates random
I/O patterns. About half of the FORTRANS that I run this program with
The following program:
extern void abort (void);
int x = 0;
extern int y __attribute((weakref("x")));
int main(void)
{
x = 1;
y = 2;
if (x != 2)
abort ();
return 0;
}
when compiled with -O2 on powerpc-darwin, unconditionally calls abort(). It
should not.
--
Summary: a
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-28 17:06 ---
Confirmed, the problem is that middle-end does not know that x and y are really
the same variable
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
I get a segmentation fault when trying to execute the
following simple program:
>cat junk2.f
program junk
character*28000 s
do i=1,28000
s(i:i) = 'a'
end do
open(3,file='junk_file',form='unformatted',access='direct',
& recl=28000)
write(3,rec=1)
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-28 17:52 ---
This is fixed in 4.1.0 by removing the mmap code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #13 from nekkar at libero dot it 2005-11-28 18:14 ---
Hi Richard
Could you explain us in details what would be in your opinion the best solution
to this problem?
Should we create a new maverick crunch target with specific division code or
what else?
--
http://gcc.gnu.o
--- Comment #2 from aoliva at gcc dot gnu dot org 2005-11-28 18:40 ---
I'd change the testcase s/weakref/alias/, so as to make it clear that the error
has nothing to do with the newly-introduced weakref, but rather with regular
aliases, that weakref builds upon.
--
http://gcc.gnu.or
Take the following example:
int f(int i, int j)
{
if (i <= j - 1)
if (i >= 0)
{
return i >= j;
}
return 0;
}
Note this might show up somewhere but I don't know if it actually does (I made
this up while looking into some missed optimizations due the patch which fixes
PR 2366
--- Comment #7 from gdr at integrable-solutions dot net 2005-11-28 18:46
---
Subject: Re: Warning "missing braces around initializer" causing problems with
tr1::array
"chris at bubblescope dot net" <[EMAIL PROTECTED]> writes:
| Actually, is a report really approriate? Writing array =
$ cat invalid_nullify.F
program ice_on_error_diagnostics
implicit none
TYPE (nonexisting_type1) t1 !, TARGET :: t1
nullify(t1%something)
end program
$ gfortran-4.0 invalid_nullify.F
In file invalid_nullify.F:3
TYPE (nonexisting_type1) t1 !, TARGET :: t1
--- Comment #3 from geoffk at geoffk dot org 2005-11-28 19:22 ---
Subject: Re: aliases, including weakref, break alias analysis
On 28/11/2005, at 10:40 AM, aoliva at gcc dot gnu dot org wrote:
> --- Comment #2 from aoliva at gcc dot gnu dot org 2005-11-28
> 18:40 ---
> I'd
[EMAIL PROTECTED]:~/src/work> cat testint.f90
module integrator
interface
function integrate(f,xmin,xmax)
implicit none
interface
function f(x)
real*8 :: f,x
intent(in) :: x
end function f
end interface
real*8 :: xmin,
--- Comment #7 from tromey at gcc dot gnu dot org 2005-11-28 20:06 ---
I'm handling this
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #5 from iwan at irs dot phy dot nrc dot ca 2005-11-28 20:22
---
Created an attachment (id=10358)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10358&action=view)
Fixes bug 25039
The patch is against revision 107612 on gcc trunc,
to be applied in gcc/libgfortran/io.
I
--- Comment #8 from jvdelisle at verizon dot net 2005-11-28 21:07 ---
Subject: Re: namelist read from non-opened file
fxcoudert at gcc dot gnu dot org wrote:
> +
> /* Is it unformatted? */
> - if (!(cf & (IOPARM_DT_HAS_FORMAT | IOPARM_DT_LIST_FORMAT)))
> + if (!(cf & (IO
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-28 21:19
---
Confirmed.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
Status|UN
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-28 21:27
---
Confirmed. Reminds a bit of PR 15809.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-28 21:33
---
Confirmed.
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
Status|UN
I am filing this right now even though I don't have a testcase because I am
running into it while trying to fix PR 23666. I don't know if this will cause
wrong code or not. I do know it will cause a missed optimization while
compiling "g++.dg/tree-ssa/pr18178.C" I have to find a testcase which f
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-28 21:44
---
Confirmed.
The F2003 (draft) standard says, in 7.4.4.1:
"C736 (R755) A subscript or stride in a foral l-triplet-spec shall not contain
a
reference to any index-name in the foral l-triplet-spec -list in which i
--- Comment #6 from janis at gcc dot gnu dot org 2005-11-28 21:48 ---
A regression hunt identified this large patch of many VPR fixes:
http://gcc.gnu.org/viewcvs?view=rev&rev=100478
r100478 | dnovillo | 2005-06-02 02:57:15 + (Thu, 02 Jun 2005) | 141 lines
--
janis at gcc dot gn
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-28 21:57
---
Confirmed. (Relevant section of the F2003 draft standard: 12.3.2.1.2).
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-28 22:13
---
With gfortran 4.2.0 20051128 I get an ICE for this code.
This slightly different code (but with basically the same error), however,
compiles and outputs 10, when we should get an error:
integer :: a
a=T1
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |echristo at gcc dot gnu dot
|dot org
--- Comment #1 from eedelman at gcc dot gnu dot org 2005-11-28 22:27
---
I can reproduce this with gfortran 4.1.0 20051128, but gfortran 4.2.0 20051128
correctly gives an error:
erik:~$ gfortran huj.f90
In file huj.f90:6
CHARACTER(LEN=*) FUNCTION F1
--- Comment #2 from eedelman at gcc dot gnu dot org 2005-11-28 22:36
---
This a duplicate of PR 24705, which was recently fixed on 4.2 and 4.0, but not
(yet?) on 4.1.
*** This bug has been marked as a duplicate of 24705 ***
--
eedelman at gcc dot gnu dot org changed:
Wh
--- Comment #5 from eedelman at gcc dot gnu dot org 2005-11-28 22:36
---
*** Bug 25081 has been marked as a duplicate of this bug. ***
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-28 22:56 ---
Even the simple code like:
int f(int i, int j )
{
int k;
k = i+ - 1;
return k < i;
}
Does not get VRP to optimize it which means we don't do that much symbolic
ranges as we should. From looking at things,
--- Comment #4 from janis at gcc dot gnu dot org 2005-11-28 23:26 ---
A regression hunt using the reduced testcase from comment #3 identified the
following patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=98066
r98066 | law | 2005-04-13 04:29:40 + (Wed, 13 Apr 2005)
--
http://gc
--- Comment #7 from amodra at bigpond dot net dot au 2005-11-28 23:37
---
Hmm, yes, you are probably correct that optimization level should not help
correct a header/library mismatch. Still, the fact remains that I can't
reproduce your problem. For good measure, I compiled both the C
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-28 23:43 ---
extract_range_from_binary_expr should do symbolic ranges for stuff like this
(or at least it seems like it should).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25145
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[m68k] undefined reference |[4.2 Regression] [m68k]
|to `__floatunsidf'
--- Comment #17 from joseph at codesourcery dot com 2005-11-28 23:43
---
Subject: Re: [4.2 Regression] Build failure on
sparc-sun-solaris2.9/arm: undefined symbol __floatunsitf
Current status:
PA needs fixing, probably similarly to ia64-hpux.
So does MIPS16.
FRV may need fixing, p
--- Comment #6 from kargl at gcc dot gnu dot org 2005-11-29 00:08 ---
The error is actually correct behavior. The comma is
not a valid character in an integer and the '(2I9)'
format is telling the compiler that you are inputting
2 integers with 9 digits each. The comma does not
short-c
--- Comment #3 from janis at gcc dot gnu dot org 2005-11-29 00:13 ---
A regression hunt identified the following patch:
http://gcc.gnu.org/viewcvs?view=rev&rev=104103
r104103 | mmitchel | 2005-09-09 18:56:16 + (Fri, 09 Sep 2005) | 15 lines
PR c++/22252
* decl.c (st
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-29 00:21 ---
This needs PR 25148 fixed to do the correct thing for comment #1 as we get the
wrong answer for a + -1 < a, we get false when we should get true.
--
pinskia at gcc dot gnu dot org changed:
What|Re
--- Comment #5 from law at redhat dot com 2005-11-29 00:22 ---
Subject: Re: [4.1/4.2 Regression] ICE in
coalesce_abnormal_edges, at tree-outof-ssa.c:646
On Mon, 2005-11-28 at 23:26 +, janis at gcc dot gnu dot org wrote:
>
> --- Comment #4 from janis at gcc dot gnu dot
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-29 00:29 ---
This causes wrong code when fixing PR 25145, comment #1.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-29 00:34 ---
I run into a different regression if we try to compile the first example in
comment #0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25145
--- Comment #7 from iwan at irs dot phy dot nrc dot ca 2005-11-29 00:35
---
(In reply to comment #6)
I'm not sure what the "correct" behavior is.
But it is a fact that gfortran is the first
compiler I have seen to respond with a runtime error,
given this format and input. This is ext
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-29 00:38 ---
Note this was the simple fix which exposes those latent bugs as far as I can
see that should work, we get the correct range but the rest of VRP goes
bonkers:
Index: tree-vrp.c
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-29 00:39 ---
I am not going to fix this now as it exposes too many VRP issues and other
issues.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #37 from aoliva at gcc dot gnu dot org 2005-11-29 00:47 ---
Subject: Bug 24991
Author: aoliva
Date: Tue Nov 29 00:47:28 2005
New Revision: 107639
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107639
Log:
PR libfortran/24991
* config/darwin.c (machopic_indirection_na
--- Comment #38 from aoliva at gcc dot gnu dot org 2005-11-29 00:56 ---
Subject: Bug 24991
Author: aoliva
Date: Tue Nov 29 00:56:16 2005
New Revision: 107640
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107640
Log:
PR libfortran/24991
* config/darwin.c (machopic_indirection_na
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-29 01:03
---
(In reply to comment #5)
> Once fold is able to do (int)(a+b) into (int)a + (int)b, the combine pass
> (15459) should be able to fix this.
I should note this is only valid for unsigned types and when -fwrapv is
su
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-29 01:32 ---
This is for ffast-math, for non fast-math, we already do it correctly.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from kargl at gcc dot gnu dot org 2005-11-29 01:55 ---
(In reply to comment #7)
> (In reply to comment #6)
> I'm not sure what the "correct" behavior is.
> But it is a fact that gfortran is the first
> compiler I have seen to respond with a runtime error,
> given this f
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-29 02:07 ---
Actually you can produce the missed optimization for g++.dg/tree-ssa/pr18178.C
with -fwrapv, we know that the range is [0, a-1] so that it has to be less than
a.
The code for ASSERTS:
i_2 = ASSERT_EXPR ;
D.2100_2
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-11-29 02:16
---
Reduced test case:
program test
dimension data(100)
read(11,end=1000 )data
1000 continue
backspace 11
backspace 11
end
I will have to check to see if this is l
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2005-11-29 02:28
---
Yes, I have a patch under review right now that fixes this. However, I am
going to add a requirement that -std=legacy or similar be invoked, otherwise we
would be non-compliant with F95 Standard which disallows c
--- Comment #4 from wilson at gcc dot gnu dot org 2005-11-29 03:39 ---
The failure happens in store_motion in gcse.c.
We have two objects on the stack with disjoint lifetimes that overlap. They
have different MEM_EXPRS, and some of the mems also have different alias sets.
They have di
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2005-11-29 03:50
---
Dang, I just noticed that Iwan had proposed a patch in comment #5 so I did my
own.
My apologies please.
Does Iwan have copyright assignment in place?
I took a different approach with my patch because I did not
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-29 04:03 ---
(In reply to comment #3)
> To repsond to this one, with -fpic/PIC we don't inline functions which can be
> overridden by other TUs.
More to the point, this testcase is only testing when inlining which means with
-f
> --- Comment #4 from wilson at gcc dot gnu dot org 2005-11-29 03:39
> ---
> The testcase doesn't fail with gcc-4.0 and up, because after tree-ssa opts
> there isn't anything left for the RTL gcse pass to do. However, I believe the
> bug is still there in the code, it is just very much h
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-29 04:04 ---
Subject: Re: [3.4 Regression] Produces wrong code
> --- Comment #4 from wilson at gcc dot gnu dot org 2005-11-29 03:39
> ---
> The testcase doesn't fail with gcc-4.0 and up, because after tree-ssa opts
>
The following compiles fine with no parameters but fails to compile with
-std=f95:
program fabort
implicit none
integer :: i1, i2, i3
open(10, status="scratch")
write(10,'(a)') "1,2 35"
rewind(10)
read(10,'(3i9)') i1,i2,i3
if(i1.ne.1) call abor
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-29 04:15 ---
This is most likely a dup of bug 20248 (hopefully I was clear in my email to
fortran@, maybe I was not).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25149
Bug seen with the RH version of gcc (gcc-3.4.4-2.fc3) but Jim Wilson says
he can reproduce this with the FSF gcc-3.4.4.
See Message-ID: <[EMAIL PROTECTED]> on gcc mailing list
and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174061
$ gcc -g -O2 -c -DSHOWBUG bug.c
bug.c: In function `bug':
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-29 05:00 ---
Confirmed fixed in 4.0.0, it is not a regression as 3.3 added TLS and it failed
until 4.0.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ghazi at gcc dot gnu dot org 2005-11-29 05:17 ---
Subject: Bug 20109
Author: ghazi
Date: Tue Nov 29 05:17:20 2005
New Revision: 107652
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107652
Log:
PR middle-end/20109
PR middle-end/25120
*
--- Comment #8 from ghazi at gcc dot gnu dot org 2005-11-29 05:17 ---
Subject: Bug 25120
Author: ghazi
Date: Tue Nov 29 05:17:20 2005
New Revision: 107652
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107652
Log:
PR middle-end/20109
PR middle-end/25120
*
--- Comment #4 from ghazi at gcc dot gnu dot org 2005-11-29 05:18 ---
Subject: Bug 20109
Author: ghazi
Date: Tue Nov 29 05:17:56 2005
New Revision: 107653
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107653
Log:
PR middle-end/20109
PR middle-end/25120
*
--- Comment #9 from ghazi at gcc dot gnu dot org 2005-11-29 05:18 ---
Subject: Bug 25120
Author: ghazi
Date: Tue Nov 29 05:17:56 2005
New Revision: 107653
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107653
Log:
PR middle-end/20109
PR middle-end/25120
*
--- Comment #10 from ghazi at gcc dot gnu dot org 2005-11-29 05:18 ---
Subject: Bug 25120
Author: ghazi
Date: Tue Nov 29 05:18:13 2005
New Revision: 107654
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107654
Log:
PR middle-end/20109
PR middle-end/25120
1 - 100 of 107 matches
Mail list logo
