--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-12-10 07:52
---
Looking into this.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Ass
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-12-10 07:47
---
Trying to find a C testcase...
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-12-10 07:47
---
Confirmed, probably platform-independent.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from burnus at gcc dot gnu dot org 2007-12-10 06:43 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00433.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34411
--- Comment #2 from tbm at cyrius dot com 2007-12-10 05:33 ---
(In reply to comment #1)
> Perhaps we could get a URL to a version of mawk that is failing.
>
> Also details about how you configured gcc and which svn revision number you
> tested, and how mawk was configured.
It's all sta
--- Comment #1 from daney at gcc dot gnu dot org 2007-12-10 05:15 ---
Perhaps we could get a URL to a version of mawk that is failing.
Also details about how you configured gcc and which svn revision number you
tested, and how mawk was configured.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #15 from danglin at gcc dot gnu dot org 2007-12-10 03:27
---
Fixed by change.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #22 from danglin at gcc dot gnu dot org 2007-12-10 03:26
---
Fixed by patch.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #21 from danglin at gcc dot gnu dot org 2007-12-10 03:17
---
Subject: Bug 34091
Author: danglin
Date: Mon Dec 10 03:17:24 2007
New Revision: 130735
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130735
Log:
PR middle-end/32889
PR target/34091
--- Comment #14 from danglin at gcc dot gnu dot org 2007-12-10 03:17
---
Subject: Bug 32889
Author: danglin
Date: Mon Dec 10 03:17:24 2007
New Revision: 130735
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130735
Log:
PR middle-end/32889
PR target/34091
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-12-10 03:15
---
I am working on a function to catch the parenthesis problem.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-12-10 02:32
---
I am seeing this also today.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-12-10 02:16
---
First, you are relying on non-portable behavior:
F95 Standard 9.4.1.5 Error branch - subpart (2)->
"The position of the file specified in the input/output statement becomes
indeterminate"
So gfortran does not
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-10 01:55 ---
Confirmed,
It also fails with 3.3 so this is not a regression.
A testcase for PPC:
template
class Tpl
{
public:
static long* MySysCall()
{
register long retval __asm__("r3");
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-12-10 01:48
---
*** Bug 33808 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-12-10 01:48 ---
On the trunk we get:
t.cc: In function 'Y<__typeof__ ((Tx() * Ty()))> operator*(X&, const Ty&)
[with Tx = double, Ty = double]':
t.cc:29: sorry, unimplemented: mangling typeof, use decltype instead
t.cc: In function
The mawk test suite doesn't pass when I build mawk with gcc 4.3 at
-O3 on mips. I cannot give you an isolated testcase but I've
narrowed it down so that someone with more experience can take a
look. I hope one of the two of you (David, Richard) can take a look.
Get mawk from upstream or Debian a
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34331
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-10 00:23 ---
This is a vectorizer vs not being able to run may_alias after it.
Confirmed.
(gdb) p debug_generic_expr (tag_type)
vector short int
(gdb) p debug_tree(tag)
unit size
align 16 symtab 0 alias set
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-10 00:10 ---
No, this should not happen, nothing should be rebuilding while doing a "make
install".
Can you attach the output of doing a "clean" make and then a "make install"
(please put them into two seperate output files)?
To "make" correctly version 4.2.2 you need to "make install" previous version
of built compiler (/cygwin/usr/local/bin), but not lower than 4.1.0. Compiler
complains on unrecognized "-Wc++-compat" which uses in makefile and which seems
appeared in the 4.1.0 version.
I think this is bug because in "
I got
FAIL: gfortran.dg/ltrans-7.f90 -O scan-tree-dump-times ltrans "transformed
loop" 1
on x86_64-unknown-linux-gnu.
--
Summary: gfortran.dg/ltrans-7.f90 doesn't work
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
--- Comment #11 from burnus at gcc dot gnu dot org 2007-12-09 23:11 ---
Patch, which fixes the test-suite failure (arrays were replaced by scalars):
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00424.html
Still left to do: ENTRY functions, see comment 6.
--
burnus at gcc dot gnu d
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-12-09 23:05 ---
Created an attachment (id=14715)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14715&action=view)
proposed patch
This is a first go at PR 34323, 34370 and 34405, so
far untested and missing some test cases.
--- Comment #3 from burnus at gcc dot gnu dot org 2007-12-09 22:55 ---
I believe this has been fixed by the patch (PR 22244):
http://gcc.gnu.org/ml/gcc-cvs/2007-12/msg00175.html
Note for gdb you still need the patches from:
http://sourceware.org/ml/gdb-patches/2007-11/msg00438.html
--- Comment #14 from burnus at gcc dot gnu dot org 2007-12-09 22:53 ---
Close as FIXED (on the trunk/4.3.0). Note, for debugging multi-dimensional
arrays one also needs the following gdb patch:
http://sourceware.org/ml/gdb-patches/2007-11/msg00438.html
--
burnus at gcc dot gnu dot
--- Comment #8 from burnus at gcc dot gnu dot org 2007-12-09 22:48 ---
I believe this has been fixed by the patch (PR 22244):
http://gcc.gnu.org/ml/gcc-cvs/2007-12/msg00175.html
Note for gdb you still need the patches from:
http://sourceware.org/ml/gdb-patches/2007-11/msg00438.html
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-12-09 22:34 ---
>+static tree get_generic_type_node_from_size(int size)
This function needs lots of improvement because the size of the modes is based
on UNIT_BIT_SIZE (I think that is the macro name) and really you can go from a
s
--- Comment #3 from nitefalll at gmail dot com 2007-12-09 22:32 ---
The actual resolution was finding the segmentation fault happened at different
points in the build process with nothing changed but hitting "make" again. That
told me it might be a hardware issue. I took off the case cov
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-12-09 22:31
---
I will investigate this one.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-12-09 21:54 ---
And here is a reduced testcase which can compiled with either the C or C++
front-ends:
int isLegalIdChar (char);
char get();
char z;
void FillBuffer ( void )
{
char c;
while(1)
{
c = get();
if (!isLegalId
--- Comment #6 from jakub at gcc dot gnu dot org 2007-12-09 21:32 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jakub at gcc dot gnu dot org 2007-12-09 21:31 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #20 from jakub at gcc dot gnu dot org 2007-12-09 21:31 ---
Fixed for 4.3 then.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Summary
--- Comment #4 from jakub at gcc dot gnu dot org 2007-12-09 21:26 ---
Subject: Bug 34178
Author: jakub
Date: Sun Dec 9 21:26:29 2007
New Revision: 130727
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130727
Log:
PR c++/34178
PR c++/34340
* repo.c (repo_
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-09 21:26 ---
Small testcase:
typedef unsigned int uint32_t __attribute__ ((__mode__ (__SI__)));
eeprom_read_block ( )
{
uint32_t serial;
f(&serial );
}
--
pinskia at gcc dot gnu dot org changed:
What|Remov
--- Comment #5 from jakub at gcc dot gnu dot org 2007-12-09 21:26 ---
Subject: Bug 34340
Author: jakub
Date: Sun Dec 9 21:26:29 2007
New Revision: 130727
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130727
Log:
PR c++/34178
PR c++/34340
* repo.c (repo_
--- Comment #1 from sjackman at gmail dot com 2007-12-09 21:08 ---
Created an attachment (id=14714)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14714&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34412
$ avr-gcc -mmcu=at90pwm316 -g -O2 -Wall -Wextra -Werror -Os -mtiny-stack
-I../.. -I.. -MMD -DBOOTLOADER -DF_CPU=1600 -c -o serial.o ../../serial.c
../../serial.c: In function ‘serial_read’:
../../serial.c:13: error: unrecognizable insn:
(insn/f 52 51 53 2 ../../serial.c:9 (set (reg:QI 28 r28)
--- Comment #1 from burnus at gcc dot gnu dot org 2007-12-09 21:03 ---
Do you have an idea, Jerry? I can reproduce it with gfortran 4.1.3, 4.2.2 and
4.3.0 and as he writes, other compilers (NAG f95, g95, ifort) work.
(Note: One needs to change "ii" into "iostat" or vice versa.)
gfortra
--- Comment #4 from ludovic at ludovic-brenta dot org 2007-12-09 20:48
---
First, read http://gcc.gnu.org/ml/gcc/2006-10/msg00303.html for a
little background information on ZCX and SJLJ in Ada.
Steps to reproduce:
- bootstrap with ada enabled (i.e. ../gcc/configure
--enable-languag
--- Comment #19 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-09
20:39 ---
Subject: Re: [4.2/4.3 Regression] ICE in reload_cse_simplify_operands, at
postreload.c:392
> Can this be closed now? Should the testcase (e.g. the #c3 one) go into the
> testsuite?
I'm still pondering w
The hang-up has been verified under various recent linux distributions (Ubuntu,
Gentoo (gcc version 4.1.2), ... ), architectures (amd64, i686) and under last
night-build (gcc version 4.3.0 20071209 (experimental) [trunk revision 130717]
(GCC)).
The code is correctly compiled without any warnings as
--- Comment #18 from jakub at gcc dot gnu dot org 2007-12-09 19:50 ---
Can this be closed now? Should the testcase (e.g. the #c3 one) go into the
testsuite?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34091
--- Comment #5 from pcarlini at suse dot de 2007-12-09 19:49 ---
(In reply to comment #4)
> is deprecated in 4.3, but it's replacement,
> doesn't appeart to be available in 4.2.
Just use
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33832
Current build of Cygwin gfortran segfaults on the call to __builtin_tgamma.
Call to tgamma in C works fine. Looks like configuration issue.
--
Summary: gamma_5.f90 segfault on Cygwin
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity
--- Comment #4 from olafvdspek at gmail dot com 2007-12-09 18:56 ---
I reported the bug below to Debian. I'm not that familiar with those headers,
but I think it'd be a good idea to not deprecate them until the replacements
have been available for quite a while.
http://bugs.debian.org/c
--- Comment #3 from olafvdspek at gmail dot com 2007-12-09 18:52 ---
Hasn't the comment from [EMAIL PROTECTED] been implemented?
AFAIK works in 4.3 and generates the deprecation warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33832
We are emitting .eh_frame data with DW_CFA_def_cfa where we could emit
DW_CFA_def_cfa_register. This makes the .eh_frame one byte larger per
occurence.
This appears to only be done for mips targets as a workaround for bugs in the
SGI assembler/linker. For targets using GNU Binutils we don't need
--- Comment #17 from danglin at gcc dot gnu dot org 2007-12-09 18:02
---
Subject: Bug 34091
Author: danglin
Date: Sun Dec 9 18:02:08 2007
New Revision: 130725
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130725
Log:
PR middle-end/32889
PR target/34091
--- Comment #13 from danglin at gcc dot gnu dot org 2007-12-09 18:02
---
Subject: Bug 32889
Author: danglin
Date: Sun Dec 9 18:02:08 2007
New Revision: 130725
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130725
Log:
PR middle-end/32889
PR target/34091
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-12-09 17:59
---
I think a runtime error would be appropriate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34405
--- Comment #10 from danglin at gcc dot gnu dot org 2007-12-09 17:47
---
Also fails on hppa64-hp-hpux11.11.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2007-12-09 17:14 ---
Dominique,
> Yes it depends of the memory content, anyway the 0 in your results should be
> spaces.
>
Ah yes. The problem is in trans-array.c(gfc_trans_array_ctor_element), where
the assignment, line 975 onwards,
--- Comment #13 from jakub at gcc dot gnu dot org 2007-12-09 17:08 ---
Subject: Bug 22244
Author: jakub
Date: Sun Dec 9 17:08:06 2007
New Revision: 130724
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130724
Log:
PR fortran/22244
* langhooks-def.h (LANG_HOOKS_G
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-12-09 16:43 ---
Not a regression since -fsee is broken since ever and the sharing verifier is
new.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from ubizjak at gmail dot com 2007-12-09 16:42 ---
Confirmed, ICEs in vectorizer pass on x86_64-pc-linux-gnu. Reduced testcase:
--cut here--
extern int ReadBlobByte (void);
void ReadRLEImage (unsigned char *p)
{
unsigned char background_color[256];
long j;
unsigne
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-12-09 16:22 ---
Confirmed. verify_flow_info right after expansion detects this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2007-12-09 16:05 ---
You brave soul for trying to compile with -fsee.
Nevertheless, yup, a bug.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tsarkov at cs dot man dot ac dot uk 2007-12-09 16:01
---
Created an attachment (id=14713)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14713&action=view)
Preprocessed sources
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34408
gcc version 4.3.0 20071209 (experimental) [trunk revision 130723] (GCC)
> /opt/gcc/bin/g++-4.3 -O2 -fsee -c scanner.cpp
scanner.cpp: In member function 'void TsScanner::FillBuffer()':
scanner.cpp:29: error: invalid rtl sharing found in the insn
(insn 39 38 36 4 scanner.cpp:17 (set
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-12-09 15:54 ---
I suppose this is related to PR34371.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from dcb314 at hotmail dot com 2007-12-09 14:40 ---
Created an attachment (id=14712)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14712&action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34407
I just tried to compile Suse Linux package GraphicsMagick-1.1.10-11
with the GNU C compiler version 4.3, snapshot 20071207 and
the compiler said
rle.c: In function 'ReadRLEImage':
rle.c:116: error: incorrect sharing of tree nodes
prologue_after_cost_adjust.421_1336 = (long unsigned int) D.8406_92;
--- Comment #3 from zadeck at naturalbridge dot com 2007-12-09 13:26
---
Subject: Re: [4.3 regression] gnat1 takes too long
to compile g-catiio.adb with SJLJ exceptions
steven at gcc dot gnu dot org wrote:
> --- Comment #1 from steven at gcc dot gnu dot org 2007-12-09 09:29
> -
--- Comment #2 from zadeck at naturalbridge dot com 2007-12-09 13:25
---
Subject: Re: [4.3 regression] gnat1 takes too long
to compile g-catiio.adb with SJLJ exceptions
steven at gcc dot gnu dot org wrote:
> --- Comment #1 from steven at gcc dot gnu dot org 2007-12-09 09:29
> -
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-12-09 13:22 ---
Same thing for direct access and
BACKSPACE, ENDFILE and REWIND.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
-
template < typename T, typename C, C T::*F >
struct X
{
};
struct Y
{
typedef X< Y, int, &Y::field_ > Z;
int field_;
};
gcc-4.1 reports:
t.cpp:8: error: incomplete type 'Y' used in nested name specifier
t.cpp:8: error: template argument 3 is invalid
comeau online:
"ComeauTest.c",
--- Comment #1 from burnus at gcc dot gnu dot org 2007-12-09 13:07 ---
NAG f95:
Error: adf.f90, line 10: Initialisation expression for BAD is not constant
ifort:
fortcom: Error: adf.f90, line 10: A data initialization-expr is not valid for
this object. [BAD]
type (bad_t) :: bad = ba
--- Comment #5 from burnus at gcc dot gnu dot org 2007-12-09 13:01 ---
Thanks for the fix and thanks Joost for the test case.
FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2007-12-09 12:58 ---
Subject: Bug 34404
Author: burnus
Date: Sun Dec 9 12:58:25 2007
New Revision: 130723
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130723
Log:
2007-12-09 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
Currently, we ignore the following:
$ cat unformatted_stream_backspace.f90
program main
open(2003,form="unformatted",access="stream")
write (2003) 1
write (2003) 2
backspace 2003
end program main
$ gfortran unformatted_stream_backspace.f90
$ ./a.out
$
This code is actually illegal, we c
--- Comment #3 from jv244 at cam dot ac dot uk 2007-12-09 12:25 ---
complex :: x
character(len=80) :: t="(1.0E-7,4.0E-3)"
read(t,*) x
END
confirmed
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #2 from hjl at lucon dot org 2007-12-09 12:15 ---
The input data file has
(2.4E-1, 0.0E+0)
It is read by
COMPLEX*16 X
...
READ(10,*) X
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #1 from hjl at lucon dot org 2007-12-09 12:14 ---
Revision 130708
http://gcc.gnu.org/viewcvs/trunk/libgfortran/io/list_read.c?r1=130708&r2=130707&pathrev=130708
has
@@ -1136,6 +1141,13 @@
exp2:
if (!isdigit (c))
+{
+ if (c == 'i' || c == 'I' || c == 'n' || c
--- Comment #4 from sam at gcc dot gnu dot org 2007-12-09 11:42 ---
Building all the system dependent files corresponding to this patch requires
access to all supported targets to update the constant value and is extremely
time consuming. This is certainly not something I am willing or a
Revision 130713 got
Running 168.wupwise ref base o2 default
*** Miscompare of te.out, see
/export/spec/src/2000/i686/spec/benchspec/CFP2000/168.wupwise/run/0002/te.out.mis
*** Miscompare of wupwise.out, see
/export/spec/src/2000/i686/spec/benchspec/CFP2000/168.wupwise/run/0002/wupwise.ou
--- Comment #4 from sam at gcc dot gnu dot org 2007-12-09 11:09 ---
Fixed in SVN trunk
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #3 from sam at gcc dot gnu dot org 2007-12-09 11:08 ---
Subject: Bug 34366
Author: sam
Date: Sun Dec 9 11:07:54 2007
New Revision: 130720
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130720
Log:
gcc/ada/
PR ada/34366
* sem_ch3.adb (Designates_T
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-12-09 11:07 ---
What target is this on?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #10 from tkoenig at netcologne dot de 2007-12-09 10:33 ---
Subject: Re: performance of pack/unpack
On Sat, 2007-12-08 at 21:57 +, jvdelisle at verizon dot net wrote:
>
> --- Comment #9 from jvdelisle at verizon dot net 2007-12-08 21:57 ---
> Subject: Re: perf
--- Comment #5 from dominiq at lps dot ens dot fr 2007-12-09 09:34 ---
> For the original, I am getting: ...
Yes it depends of the memory content, anyway the 0 in your results should be
spaces.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34396
--- Comment #1 from steven at gcc dot gnu dot org 2007-12-09 09:29 ---
A test case would be nice... Asking people to grok a email list thread and do
the research probably will not help you getting this bug fixed.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pault at gcc dot gnu dot org 2007-12-09 09:29 ---
For the original, I am getting:
|cd| |a|
99 100 0 0 0
97 0 0 0 0
and for comment #3:
|cd| |ae|
99 100 0 0 0
97 101 0 0 0
Today's trunk on x86_ia64/fc5.
Paul
--
http://gcc
--- Comment #9 from pault at gcc dot gnu dot org 2007-12-09 09:19 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #10 from pault at gcc dot gnu dot org 2007-12-09 09:19 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #8 from pault at gcc dot gnu dot org 2007-12-09 09:17 ---
Subject: Bug 32129
Author: pault
Date: Sun Dec 9 09:17:24 2007
New Revision: 130719
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130719
Log:
2007-12-09 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #9 from pault at gcc dot gnu dot org 2007-12-09 09:17 ---
Subject: Bug 31487
Author: pault
Date: Sun Dec 9 09:17:24 2007
New Revision: 130719
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130719
Log:
2007-12-09 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #3 from kayhayen at gmx dot de 2007-12-09 08:28 ---
This is to confirm that the patch cleanly applied to a couple of snapshots
since, the last one I tested was "gcc-snapshot-20071202" as found in the Ubuntu
Hardy archives.
Would it be possible to apply it? And now that it ha
--- Comment #5 from dannysmith at users dot sourceforge dot net 2007-12-09
08:00 ---
Fixed for 4.3.0 by
http://gcc.gnu.org/viewcvs?view=rev&revision=126903
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
---
92 matches
Mail list logo