On 8/8/07, Daniel Berlin [EMAIL PROTECTED] wrote:
I also haven't necessarily said what Ollie has proposed is a bad idea.
I have simply said the way he has come up with what he proposed is
not the way we should go about this. It may turn out he has come up
with exactly the representation we
On 8/8/07, Ollie Wild [EMAIL PROTECTED] wrote:
On 8/8/07, Daniel Berlin [EMAIL PROTECTED] wrote:
I also haven't necessarily said what Ollie has proposed is a bad idea.
I have simply said the way he has come up with what he proposed is
not the way we should go about this. It may turn out
My automated nightly build failed to bootstrap this evening on i386-
pc-linux-gnu. This is for trunk rev. 127311, and the error is:
/home/fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/xgcc -B/home/
fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/ -B/home/fx/
gfortran_nightbuild/irun
Aurora SPARC Linux release 2.99 (Angel)/TI UltraSparc IIi (Sabre) sun4u:
binutils-2.17.50.0.3-6.sparc.sparc
bison-2.3-2.1.sparc
dejagnu-1.4.4-5.1.noarch
expect-5.43.0-5.1.sparc
gcc-4.1.1-30.1.sparc
glibc-2.5-3.1.sparcv9
glibc-2.5-3.1.sparc64
glibc-devel-2.5-3.1.sparc
glibc-devel-2.5-3.1.sparc64
Yesterday by mistake I started some private discussion with Daniel.
I will forward his answer too.
Begin forwarded message:
From: Cupertino Miranda [EMAIL PROTECTED]
Date: August 9, 2007 2:24:04 AM CEDT
To: Daniel Berlin [EMAIL PROTECTED]
Subject: Re: Fixed function compilation order
On Aug
Here is the answer.
Begin forwarded message:
From: Daniel Berlin [EMAIL PROTECTED]
Date: August 9, 2007 2:31:08 AM CEDT
To: Cupertino Miranda [EMAIL PROTECTED]
Subject: Re: Fixed function compilation order
On 8/8/07, Cupertino Miranda [EMAIL PROTECTED] wrote:
On Aug 9, 2007, at 2:03 AM,
On Fri, Aug 03, 2007 at 03:49:32PM +0100, Dave Korn wrote:
Yes, absolutely so, we already know that there are problems there. For
references, see the threads Deep CSE bug![*] and Bogus REG_EQUIV note
generation[**] (subject line was wrong, should have been REG_EQUAL all along)
from June
On 09 August 2007 13:25, Rask Ingemann Lambertsen wrote:
On Fri, Aug 03, 2007 at 03:49:32PM +0100, Dave Korn wrote:
Yes, absolutely so, we already know that there are problems there. For
references, see the threads Deep CSE bug![*] and Bogus REG_EQUIV note
generation[**] (subject line
Hello,
the bootstrap failure you are seeing is caused by my decompose
multiword shift patch:
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00419.html
It is the same failure as reported by Andreas Tobler:
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00533.html
I don't have access to a sparc
Windows XP Pro/SP2 cygwin Pentium M processor 2.13GHz system with packages:
binutils 20060817-1 2.17.50 20060817
bison2.3-1 2.3
cygwin 1.5.24-2 (rev. 1.46 of newlib's stdio.h)
dejagnu 20021217-2 1.4.2.x
expect
On 09 August 2007 14:39, Christian Joensson wrote:
cc1: warnings being treated as errors
../../gcc/gcc/tree.c: In function 'initializer_zerop':
../../gcc/gcc/tree.c:7694: error: passing argument 1 of 'fixed_zerop'
discards qualifiers from pointer target type
make[3]: *** [tree.o] Error 1
Hi,
I am seeing an address error exception caused by the gcc optimizer -O1.
I have narrowed it down to the following function:
static void varcopy(PVAR *pvar1, PVAR *pvar2) {
memcpy(pvar1,pvar2,sizeof(PVAR));
}
Being the sizeof(PVAR) 160 bytes.
The exception is caused on an sd instruction
Alex Gonzalez [EMAIL PROTECTED] writes:
I was under the assumption that the compiler made sure that it doesn't
store a doubleword that is not aligned on a doubleword boundary. Is
this a bug in the optimizer?
If the pointers are not correctly aligned for their target type then you
are invoking
Alex Gonzalez wrote:
Hi,
I am seeing an address error exception caused by the gcc optimizer -O1.
I have narrowed it down to the following function:
static void varcopy(PVAR *pvar1, PVAR *pvar2) {
memcpy(pvar1,pvar2,sizeof(PVAR));
}
Being the sizeof(PVAR) 160 bytes.
The exception is
Hi,
I'll try to come up with a short test.
I have narrowed it a bit more. The PVAR structure contains a long long
variable ( with a sizeof 8 and an alignof 8 for my architecture). If I
take out the long long variable, the compiler uses sdl instructions
instead of sd and the exception doesn't
On Thursday 09 August 2007, Alex Gonzalez wrote:
Hi,
I'll try to come up with a short test.
I have narrowed it a bit more. The PVAR structure contains a long long
variable ( with a sizeof 8 and an alignof 8 for my architecture). If I
take out the long long variable, the compiler uses sdl
FX Coudert wrote:
My automated nightly build failed to bootstrap this evening on i386-
pc-linux-gnu. This is for trunk rev. 127311, and the error is:
/home/fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/xgcc -B/home/
fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/ -B/home/fx
Ollie == Ollie Wild [EMAIL PROTECTED] writes:
Ollie 1. Is pointer to member migration worthwhile? Can other languages
Ollie besides C++ benefit from this?
Not Java. You might ask Andrea about CLR though.
Ollie 4. Is a migration of virtual functions and virtual function tables
Ollie
Michael == Michael Matz [EMAIL PROTECTED] writes:
Michael Yes, devirtualization. But I wonder if you really need class
Michael hierarchies for this (actually I'm fairly sure you don't).
I'm generally in favor of what you talked about in this note and
others, and also Danny's overall approach
On Thu, Aug 09, 2007 at 02:29:28PM -0600, Tom Tromey wrote:
Also in Java it is possible to devirtualize calls in some situations
where only a bound on the type is known. For instance at a call site
we might know that all possible targets are derived from a class where
the virtual method is
On Thu, Aug 09, 2007 at 02:11:34PM -0700, Joe Buck wrote:
On Thu, Aug 09, 2007 at 02:29:28PM -0600, Tom Tromey wrote:
Also in Java it is possible to devirtualize calls in some situations
where only a bound on the type is known. For instance at a call site
we might know that all possible
Could someone provide a hint for me? I'm trying to put in real
prototypes for a builtin function where the arguments don't follow the
default promotion rules. Specifically, one of the arguments is a
reference type (like C++'s int). However, I'm bumping into two
problems:
1. The compiler emits
Hi,
I've been looking at the cfg that gcc dumps to a file. I'm noticing that
the code is transformed in the cfg. Especially the short circuited
expressions and the ternary operator for C/C++. Is there a particular
algorithm gcc uses to transform the original AST into the modified version
in the
On 8/9/07 4:09 PM, Bob Rossi wrote:
Does anyone know where the code is that does this transformation so I
can look for myself?
The conversion to GIMPLE does some of that, then the lowering into Low
GIMPLE and the CFG cleanups do the rest. The files you want to look at
are gimplify.c for all
Daniel Berlin wrote:
This is the source of my current woes, as this may involve virtual
function resolution, which can't be done with the information
currently available to the middle end.
Ollie, IIRC, you posted an example where, together with your front-end
lowering patch (i.e., with the
Andreas Meier wrote:
You have forgotten the regressions with target milestone 4.2.1 and
without a target milestone.
Thank you for pointing that out. The omission of 4.2.1 is definitely
wrong, and I have fixed the front page with this patch. However, there
should be no regressions without a
I'm hoping I can get it to do what I want, if only I can get the MI to
treat the function definition given to it by the target as the one
true definition, and not just some advisory one.
On 8/9/07, Ollie Wild [EMAIL PROTECTED] wrote:
On 8/9/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Daniel Berlin wrote:
This is the source of my current woes, as this may involve virtual
function resolution, which can't be done with the information
currently available to the middle
Somebody signed up gcc@gcc.gnu.org to gmail.
Bad sign.
- Original Message -
From: Gmail Team [EMAIL PROTECTED]
To: django porter gcc@gcc.gnu.org
Sent: Thursday, August 09, 2007 6:21 PM
Subject: Your Gmail account, [EMAIL PROTECTED], has been created
Congratulations on creating your brand new Gmail account,
[EMAIL PROTECTED]
Please keep
Congratulations on creating your brand new Gmail account,
[EMAIL PROTECTED]
Please keep this email for your records, as it contains an
important verification code that you may need should you ever
encounter problems or forget your password.
You can login to your account at http://mail.google.com/
DJ Delorie [EMAIL PROTECTED] writes:
Is there a trick to this? I need this type of functionality because
some builtins modify multiple values, so a simple return value is
insufficient, plus this worked with older versions of gcc so our users
are used to it syntax-wise.
I've never found a
On 8/9/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Daniel Berlin wrote:
This is the source of my current woes, as this may involve virtual
function resolution, which can't be done with the information
currently available to the middle end.
Ollie, IIRC, you posted an example where,
On 8/9/07, Joe Buck [EMAIL PROTECTED] wrote:
On Thu, Aug 09, 2007 at 02:29:28PM -0600, Tom Tromey wrote:
Also in Java it is possible to devirtualize calls in some situations
where only a bound on the type is known. For instance at a call site
we might know that all possible targets are
Summary
---
We entered Stage 2 on July 6th. I plan to put us into Stage 3 on
September 10th. At that point, we will accept only bug-fixes -- no
more new features until Stage 1 for GCC 4.4.
Are there any folks out there who have projects for Stage 1 or Stage 2
that they are having trouble
On Thu, 9 Aug 2007, DJ Delorie wrote:
Could someone provide a hint for me? I'm trying to put in real
prototypes for a builtin function where the arguments don't follow the
default promotion rules. Specifically, one of the arguments is a
reference type (like C++'s int). However, I'm bumping
I don't know about using reference types, but there are several math
builtins that return multiple values, the extra ones via pointer
arguments. E.g. see frexp, lgamma_r, modf, remquo and/or sincos.
Like I said, I'm kinda locked into the syntax. People have been using
these builtins for
On Thu, 9 Aug 2007, Andreas Krebbel wrote:
Hello,
the bootstrap failure you are seeing is caused by my decompose
multiword shift patch:
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00419.html
It is the same failure as reported by Andreas Tobler:
hi, all
i want to ask, why free function did not do properly as it expected
(happened in test_malloc.c), the usage memory (using malloc) still exist
please help me, i have another program it, doing malloc continously, and
free it when not needed, this happened several times,
after some looping,
My automated nightly build failed to bootstrap this evening on
i386-pc-linux-gnu. This is for trunk rev. 127311, and the error is:
/home/fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/xgcc
-B/home/fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/
-B/home/fx/gfortran_nightbuild/irun-20070809/i386
--- Comment #4 from andreasmeier80 at gmx dot de 2007-08-09 08:43 ---
It worked well with r126900, but did not with r126976
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32941
--- Comment #1 from irar at il dot ibm dot com 2007-08-09 08:44 ---
I got this too on x86_64-linux.
I guess the guilty patch is
r127306 | chaoyingfu | 2007-08-09 01:29:12 +0300 (Thu, 09 Aug 2007) | 213 lines
since it added the function fixed_zerop:
* tree.c
...
Aurora SPARC Linux release 2.99 (Angel)/TI UltraSparc IIi (Sabre) sun4u:
binutils-2.17.50.0.3-6.sparc.sparc
bison-2.3-2.1.sparc
dejagnu-1.4.4-5.1.noarch
expect-5.43.0-5.1.sparc
gcc-4.1.1-30.1.sparc
glibc-2.5-3.1.sparcv9
glibc-2.5-3.1.sparc64
glibc-devel-2.5-3.1.sparc
glibc-devel-2.5-3.1.sparc64
Aurora SPARC Linux release 2.99 (Angel)/TI UltraSparc IIi (Sabre) sun4u:
binutils-2.17.50.0.3-6.sparc.sparc
bison-2.3-2.1.sparc
dejagnu-1.4.4-5.1.noarch
expect-5.43.0-5.1.sparc
gcc-4.1.1-30.1.sparc
glibc-2.5-3.1.sparcv9
glibc-2.5-3.1.sparc64
glibc-devel-2.5-3.1.sparc
glibc-devel-2.5-3.1.sparc64
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-09 09:08 ---
*** This bug has been marked as a duplicate of 33029 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-09 09:08 ---
*** Bug 33030 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33029
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-09 09:18 ---
Because placement new is required to reproduce this bug and the front-end is
where the broken code happens already, then the patch to fix PR 29286 is the
cause.
The problem is in build_new_1 where we create a
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-09 09:35
---
What about the following:
Index: gfortran.h
===
--- gfortran.h (revision 127224)
+++ gfortran.h (working copy)
@@ -1865,6 +1865,7 @@ typedef
--- Comment #4 from jbuehler at spirentcom dot com 2007-08-09 11:38 ---
Created an attachment (id=14045)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14045action=view)
gcc 4.0.4 global register variable optimizer patch
The attached patch fixes the optimizer bug for gcc 4.0.4 and
gcc-4.3-20070727 fails with ICE on code:
---
templateclass A
struct a {
templateclass B
struct b {
templateclass C
void f()
{
struct g
{
--- Comment #4 from theodore dot papadopoulo at sophia dot inria dot fr
2007-08-09 12:02 ---
Created an attachment (id=14046)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14046action=view)
A new more minimal test case
The same program was still working with gcc version 4.3.0
--- Comment #5 from andreasmeier80 at gmx dot de 2007-08-09 12:52 ---
It worked well with r126941, but did not with r126959
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32941
Hello!
The undefined variable LINUX_DYNAMIC_LINKER, included in the Variable LINK_SPEC
in the file gcc-4.2.1/gcc/config/arm/linux-elf.h lines 56-68 causes an error
during compilation of gcc-4.2.1/gcc/gcc.c at line 740. The error was:
path/gcc-4.2.1/gcc/gcc.c:740: error: expected , or ;
--- Comment #10 from hjl at lucon dot org 2007-08-09 14:15 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00450.html
--
hjl at lucon dot org changed:
What|Removed |Added
When using the transfer intrinsic to convert a character string to an array of
integers, and the string does not fit exactly into the integer array data
block, the resultant integer array is scope dependent, with the same code
giving a different resultant integer array in different
/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
/test/gnu/gcc/gcc/gcc/testsui
te/gfortran.dg/PR19754_2.f90 -O1 -pedantic-errors
-L/test/gnu/gcc/objdir/hp
pa64-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11
/./libgfortran/.libs
--- Comment #2 from matz at gcc dot gnu dot org 2007-08-09 15:50 ---
Fixed with my checkin of rev 127316.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-09 15:50 ---
Could you please tell us your gfortran version? (gfortran -v, the gcc-version
line is of most interest.)
Not that TRANSFER is free of bugs, but it produces here 4.3.0 20070808
(x86_64-unknown-linux-gnu) the same
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-09 15:59 ---
This is undefined code, when I rewrote most of the transfer code for scalars, I
had asked what happens when the sizes did not match and everyone I asked said
it was undefined behavior.
--
--- Comment #9 from dcb314 at hotmail dot com 2007-08-09 16:03 ---
(In reply to comment #8)
I suggest taking a technique from the STL and using an auto_array class
In practice, I find both STL and Boost are rarely used.
Such advanced tools are fine for experienced C++ programmers.
--- Comment #6 from andreasmeier80 at gmx dot de 2007-08-09 16:07 ---
It worked well with r126947, but did not with r126951
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32941
This has probably already been submitted by Daniel Franke or Jerry DeLisle.
I am just trying to see if I can work this system.
FORTRAN NAMELIST Run Time Problem
The FORTRAN statement
READ(5, nml=CODE)
should read through the input file (connected to device number 5)
--- Comment #7 from sje at cup dot hp dot com 2007-08-09 17:02 ---
Created an attachment (id=14047)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14047action=view)
untested patch
I can't reliably reproduce the problem but the attached patch may fix it. It
removes the sort and
--- Comment #3 from daney at gcc dot gnu dot org 2007-08-09 17:06 ---
I will commit n32/n64 support shortly.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from aph at gcc dot gnu dot org 2007-08-09 17:44 ---
I've created abranch for this work at
svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-eabi-branch
It's mostly done, but there are still some bugs. I'll post the patches to the
gcc list when they're in a fit state.
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-09
17:57 ---
Subject: Re: New: Unsatisfied symbol lroundl in file libgfortran.sl
The symbol is from misc_specifics.o.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33038
--- Comment #5 from tromey at gcc dot gnu dot org 2007-08-09 18:05 ---
See comment #3. The installation manual explains the correct way to
configure and build. I'm closing this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tromey at gcc dot gnu dot org 2007-08-09 18:07 ---
Yup, it's a bug.
We aren't really fixing bugs in the old front end though.
I'm closing it because this is a weird case and has a couple
simple workarounds.
--
tromey at gcc dot gnu dot org changed:
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-09 18:39 ---
I think this is a duplicate of PR 33019.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33039
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-09 18:41 ---
http://gcc.gnu.org/ml/fortran/2007-08/msg00119.html
http://gcc.gnu.org/ml/fortran/2007-08/msg00122.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33038
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-09
18:41 ---
Subject: Re: New: Unsatisfied symbol lroundl in file libgfortran.sl
The symbol is from misc_specifics.o.
It looks like lroundl there is an implementation using roundl. There
is an implementation of
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-09 18:54 ---
This is undefined code, when I rewrote most of the transfer code for scalars,
I
had asked what happens when the sizes did not match and everyone I asked said
it was undefined behavior.
Well, nonetheless
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-08-09 19:14 ---
Right now, I'd rather work on something else.
Unassigning myself (for now, at least).
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--
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 #8 from andreasmeier80 at gmx dot de 2007-08-09 19:24 ---
The regression was caused by the following patch
New Revision: 126951
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126951
Log:
2007-07-26 Richard Guenther [EMAIL PROTECTED]
toplev/
*
--- Comment #9 from andreasmeier80 at gmx dot de 2007-08-09 19:33 ---
I'm now testing the patch from Comment #7.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32941
The following reduced example, based on
http://www.lrz-muenchen.de/services/software/mathematik/gsl/fortran/, gives an
segmentation fault:
fgsl.f90: In function 'fgsl_multifit_fdfsolver_jac':
fgsl.f90:24: internal compiler error: Segmentation fault
valgrind shows:
==21413== Invalid read of size
--- Comment #8 from burnus at gcc dot gnu dot org 2007-08-09 21:28 ---
Subject: Bug 33001
Author: burnus
Date: Thu Aug 9 21:27:52 2007
New Revision: 127321
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127321
Log:
2007-08-09 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-09 21:37 ---
Subject: Bug 32813
Author: pinskia
Date: Thu Aug 9 21:36:27 2007
New Revision: 127322
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127322
Log:
2007-08-09 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-08-09 21:39 ---
Subject: Bug 32796
Author: pinskia
Date: Thu Aug 9 21:39:08 2007
New Revision: 127323
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127323
Log:
2007-08-09 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-08-09 21:39 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-09 21:40 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from patchapp at dberlin dot org 2007-08-09 21:45 ---
Subject: Bug number PR 33020
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-08/msg00604.html
--
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-09 21:51
---
(In reply to comment #3)
It looks like lroundl there is an implementation using roundl. There
is an implementation of roundl using ceill, but ceill isn't available.
This has been fixed since, sorry for the
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-09 21:54
---
(In reply to comment #1)
I have looked into this bug and I think it is an HP math lib bug. The 64 bit
powf function is using %fr12R but not saving/restoring it the way it is
supposed to. I have a query in to
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-09 21:56
---
Still can't reproduce this on hppa2.0w-hp-hpux11.31. I'm starting to think that
printf might be broken there, after all. Since it's a corner case on a platform
that is not the current one, I'd like to close it as
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-09 21:58
---
The patch in the previous comment wasn't even building, here is a one that
regtests and that I submitted to review.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from burnus at gcc dot gnu dot org 2007-08-09 22:03 ---
Subject: Bug 32987
Author: burnus
Date: Thu Aug 9 22:02:32 2007
New Revision: 127324
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127324
Log:
2007-08-09 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #9 from burnus at gcc dot gnu dot org 2007-08-09 22:08 ---
FIXED for gfortran 4.3.0; gfortran now accepts the tab; it checks also at
compile time for the tab character and gives either a warning (-std=gnu/legacy)
or an error (-std=f95/f2003) if a tab has been found.
--
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-09 22:20
---
Patch submitted for review.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from patchapp at dberlin dot org 2007-08-09 22:20 ---
Subject: Bug number PR 31629
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-08/msg00607.html
--
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-09 22:23 ---
Some more debugging - I modified gfc_trans_structure_assign to:
--
cm = expr-ts.derived-components; i = 1;
for (c = expr-value.constructor; c; c = c-next, cm = cm-next)
{
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||32630
nThis||
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-08-09 23:27
---
Regarding the test case:
codechar='Improper lower case name',X=-3.0/
Fortran 95 Standard 10.9.1 states:
If a processor is capable of representing letters in both upper and lower
case, a group name or
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from jsm28 at gcc dot gnu dot org 2007-08-09 23:39 ---
Created an attachment (id=14048)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14048action=view)
Candidate patch from 2005
Here's my patch from 2005 as requested.
--
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-08-09 23:37
---
*** Bug 33019 has been marked as a duplicate of this bug. ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 164 matches
Mail list logo
