--- Comment #1 from tbm at cyrius dot com 2008-09-11 06:36 ---
Created an attachment (id=16290)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16290&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37474
Jakub, thanks for fixing PR37419 so quickly. I can confirm that the
testcase from this bug now works. However, there's a second testcase
I have that still shows a similar problem with current trunk (revision
140257):
(sid)1151:[EMAIL PROTECTED]: ..4.3-2008-09-11-r140257/gcc] ./cc1 -quiet -O3
~/g
--- Comment #2 from burnus at gcc dot gnu dot org 2008-09-11 06:01 ---
I cannot reproduce the problem with gfortran 4.1, 4.2, 4.3 or 4.4 on
x86-64-linux with either -m32 or -m64, which makes debugging not easier.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37472
--- Comment #12 from luisgpm at linux dot vnet dot ibm dot com 2008-09-11
05:18 ---
This patch (revision 140068) breaks SPEC2000's 200.sixtrack benchmark for
POWER6 due to miscompares. Reverting this patch solves the problem. Not sure
what specific problem was introduced. I can isolate
The following testcase compiled with -O -fPIC results in a non-PLT call to
A::check. On x86_64 that means an R_X86_64_PC32 reloc, which the linker later
correctly complains about if we are building a shared library. Curiously, if
either or both of the typedefs are removed, you get the code I'd ex
--- Comment #1 from sdirkse at gams dot com 2008-09-11 00:56 ---
Created an attachment (id=16289)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16289&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37472
If I do write (6,*) 'x=', x for a double, I get lots of stars for doubles in
a common block when I do a 64-bit compile. The output is OK for 32-bit or for
doubles not in common. Here's some output, I'll try attaching the test case
too.
sigvm:/export/home/distrib/lang/f90$make && ./bug
gfortra
I was looking at some code generation for an internal benchmark when I noticed
this. With the current trunk on powerpc, we get a mfcr which is slow for the
cell (and most likely other PPCs too) as we pulled too many cmps with some
loops.
A simple example:
int f(int b, int l, int d, int c, int e)
{
--- Comment #2 from kargl at gcc dot gnu dot org 2008-09-10 22:48 ---
See the thread started at
http://gcc.gnu.org/ml/fortran/2008-01/msg00104.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37469
--- Comment #1 from paolo dot carlini at oracle dot com 2008-09-10 22:46
---
Johannes, can you have a look? I would suggest uglifying to something like
__log2 instead of inventing something else in the user 'namespace'. Also, the
comment before the function is wrong about 0 returned for
Line 112 of parallel/base.h declares an inline function log2. This name is in
conflict with any usage of math.h log2 and causes compilation errors for
programs using pmode and math.h. Changing the calls from log2 to xlog2
throughout the subdir parallel/*.h files (base.h, losertree.h,
multiseq_sel
--- Comment #6 from bkoz at redhat dot com 2008-09-10 21:46 ---
Subject: Re: support for standard layout types
> > 1) be able to inherit from "C" POD and be standard layout
> > 2) be able to have deleted ctor/copy ctor and be standard layout
> > 3) able to do aggregate init when 1, 2
--- Comment #1 from burnus at gcc dot gnu dot org 2008-09-10 21:35 ---
Mark as ice-on-valid-code (seems to give reliably an ICE on i64 systems).
H.J., thanks for the analysis!
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from sje at cup dot hp dot com 2008-09-10 21:22 ---
Created an attachment (id=16288)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16288&action=view)
Smaller test case
Here is a smaller test case cut down from GCC sources.
--
http://gcc.gnu.org/bugzilla/show_b
-linux/gcc/f951
/export/gnu/src/gcc-work/gcc/gcc/testsuite/gfortran.dg/parameter_array_init_3.f90
-quiet -dumpbase parameter_array_init_3.f90 -mtune=generic -auxbase
parameter_array_init_3 -O -pedantic-errors -version -o parameter_array_init_3.s
-fintrinsic-modules-path finclude
GNU Fortran (GCC) version
--- Comment #9 from vmakarov at redhat dot com 2008-09-10 21:16 ---
There are 66K allocnos and 3M live ranges in function testsuite. Fixing the
problem in IRA will take some time. I hope the patch will be ready in a few
days.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
--- Comment #5 from jakub at gcc dot gnu dot org 2008-09-10 21:10 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from jakub at gcc dot gnu dot org 2008-09-10 21:09 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-10 21:09 ---
Subject: Bug 37338
Author: jakub
Date: Wed Sep 10 21:08:17 2008
New Revision: 140249
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140249
Log:
PR middle-end/37338
* gimplify.c (gimplify_body):
--- Comment #4 from jakub at gcc dot gnu dot org 2008-09-10 21:07 ---
Subject: Bug 36904
Author: jakub
Date: Wed Sep 10 21:06:25 2008
New Revision: 140247
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140247
Log:
PR target/36904
* config/rs6000/rs6000-c.c (rs600
--- Comment #2 from burnus at gcc dot gnu dot org 2008-09-10 20:34 ---
Close as INVALID.
I hope your problem is solved now. If not, I suggest to write to the mailing
list.
(By the way, on can find quite often code like
integer, parameter :: dp = kind(1.0d0)
real(kind=dp) :: sq2 =
--- Comment #9 from burnus at gcc dot gnu dot org 2008-09-10 20:25 ---
(In reply to comment #8)
> Indeed, can be closed - thanks
Close as FIXED based on that comment.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-09-10 19:43 ---
*** Bug 37467 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-10 19:43 ---
*** This bug has been marked as a duplicate of 37418 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-10 19:42 ---
-i8 does not exist anyways, it is -fdefault-integer-8.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
Files with the suffix .F are first sent to the C preprocessor. When I combine
this with -i8 (specifying 64 bit integers), I get the following error. It seems
that the -i8 is mistakenly sent to the C preprocessor.
gfortran -c -i8 -fno-range-check -ffixed-line-length-120
-fno-second-underscore -fpi
--
aesok at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aesok at gcc dot gnu dot org
|dot org
/*
gcc-4.4-20080905 -O0 -c foo.c # ICE verify_gimple failed
gcc-4.3.1 -O0 -c foo.c # compiles normally
*/
extern void __attribute__((__noreturn__))
error_notreached(const char * file, unsigned int line);
typedef void __attribute__((__noreturn__))
(*A)(void** B);
void __attribute__((__n
Reported by geckosenator on avrfreaks.net
Code:
int sat;
static volatile long data[3];
static volatile int datacount[3];
static volatile int chan;
static volatile long val;
int __attribute__((always_inline)) transfer(int data)
{
return (*(int *)((0x00)));
}
int init_status;
lon
gt;
PR middle-end/37333
* gcc.c-torture/compile/20080910-1.c: New testcase.
Added:
trunk/gcc/testsuite/gcc.c-torture/compile/20080910-1.c
Modified:
trunk/gcc/testsuite/ChangeLog
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37333
--- Comment #7 from domob at gcc dot gnu dot org 2008-09-10 19:04 ---
The problem is that gfc_interpret_float does not set the default mpfr precision
to the value for its kind parameter but leaves the setting that is already
present. This is presumably the reason why inserting the dummy
--- Comment #1 from mrs at apple dot com 2008-09-10 18:28 ---
radr://6202462
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37465
--- Comment #8 from toon at moene dot indiv dot nluug dot nl 2008-09-10
18:18 ---
Indeed, can be closed - thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34567
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-09-10 18:12
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #13 from tbm at cyrius dot com 2008-09-10 18:09 ---
Sorry, I made a mistake. I used a tar ball from yesterday instead of the
new tar ball from today I prepared...
Yes, it's fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37333
--- Comment #11 from tbm at cyrius dot com 2008-09-10 18:06 ---
Sorry, my "20080910" build really was 20080909. I can confirm it's fixed.
--
tbm at cyrius dot com changed:
What|Removed
--- Comment #10 from tbm at cyrius dot com 2008-09-10 18:03 ---
Err, wait a sec.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37385
class A {
virtual int B() { return 0; }
};
class B: A {
B() { }
};
gives an error, but should compile (as gross as it is). I'm hoping there is a
prohibition against it, but didn't find one.
--
Summary: ctors never override virtual functions
Product: gcc
Vers
: internal compiler error: in set_mem_alias_set, at
emit-rtl.c:1784
Please submit a full bug report,
with preprocessed source if appropriate.
gcc version 4.4.0 20080909 (experimental) [trunk revision 127646] (Debian
20080910-1)
--
tbm at cyrius dot com changed:
What
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-09-10 17:58
---
> This is with revision 140005, on gcc30.fsffrance-gnu.org.
> Just when I thought I had a big-endian machine :-)
Even if it bootstrapped, you wouldn't have one. :-) Try SPARC instead.
--
ebotcazou at gcc dot
--- Comment #5 from janis at gcc dot gnu dot org 2008-09-10 17:52 ---
I made some mistakes in my previous comments; -ftree-fre is part of -O1, and
what I meant to say is that calculix gets wrong results for "-O1 -ffast-math"
but correct results for "-O1 -fno-tree-fre -ffast-math.h". The
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-09-10 17:51
---
It also works for me on i386-darwin with revision 140239 where it failed with
revision 139912. I will reduce the testcase that Martin added and then commit
it to the testsuite since I see there was no testcase ad
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-10 17:38 ---
Most likely related to PR 37426.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-09-10 17:37 ---
THis part of the bootstrap failure was fixed by:
2008-09-02 Jakub Jelinek <[EMAIL PROTECTED]>
* config/alpha/alpha.c (va_list_skip_additions,
alpha_stdarg_optimize_hook, alpha_gimplify_va_arg_1): T
This is with revision 140005, on gcc30.fsffrance-gnu.org.
Just when I thought I had a big-endian machine :-)
make[4]: quittant le répertoire «
/home/tkoenig/gcc-bin/alphaev56-unknown-linux-gnu/libgcc »
make[3]: quittant le répertoire «
/home/tkoenig/gcc-bin/alphaev56-unknown-linux-gnu/libgcc
--- Comment #11 from hjl dot tools at gmail dot com 2008-09-10 17:16
---
(In reply to comment #10)
> Created an attachment (id=16287)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16287&action=view) [edit]
> Preprocessed source
>
I can't reproduce it:
[EMAIL PROTECTED] gcc]$ ./
--- Comment #11 from paolo dot carlini at oracle dot com 2008-09-10 16:51
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Stat
--- Comment #10 from paolo at gcc dot gnu dot org 2008-09-10 16:49 ---
Subject: Bug 37455
Author: paolo
Date: Wed Sep 10 16:48:47 2008
New Revision: 140238
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140238
Log:
2008-09-10 Paolo Carlini <[EMAIL PROTECTED]>
PR libst
--- Comment #3 from hjl dot tools at gmail dot com 2008-09-10 16:48 ---
Works on Fedora 9.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Stat
--- Comment #2 from hjl dot tools at gmail dot com 2008-09-10 16:48 ---
I verified that on Fedora 9 there is no regression between
revision 140029 and 140030 on Intel Core 2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37462
->
Re: dict slice in python (translating perl to python)
gcc-bugs
<-- Thread -->
<-- Date -->
Re: dict slice in python (translating perl to python)
B
Wed, 10 Sep 2008 09:43:55 -0700
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-09-10 16:25 ---
These constraints are supposed to be valid when in gimple, not generic. Maybe
the documentation in tree.def should reflect that (there is no generic type
system, if there was, it would be the much stricter that fold
--- Comment #9 from paolo dot carlini at oracle dot com 2008-09-10 16:20
---
This is a regression, not horribly serious still a regression.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #1 from hp at gcc dot gnu dot org 2008-09-10 16:19 ---
Oops, pinskia is libobjc maintainer, not objc maintainer...
CC:ed the listed maintainers.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #8 from M dot Froehlich at science-computing dot de 2008-09-10
16:13 ---
Fine!
Thanks!
Mathias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37455
Now that i386-pc-solaris2.10 bootstraps again after the IRA merge, the first
testsuite run revealed that all eh tests fail, affecting at least the g++
tests,
ada/acats and libjava. The symptom is always the same; I take
FAIL: g++.dg/eh/alias1.C execution test
as an example.
Running alias1.exe u
--- Comment #6 from domob at gcc dot gnu dot org 2008-09-10 16:08 ---
> -fdump-parse-tree gives
> ASSIGN MAIN__:rd 5.31837115e-315_8
> ASSIGN MAIN__:z (complex 5.3183711317956924e-315_8 0_8)
> ASSIGN MAIN__:r 0
> IF (/= MAIN__:z __convert_r8_c8[[((MAIN__:rd))]])
>
--- Comment #3 from spop at gcc dot gnu dot org 2008-09-10 16:06 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #7 from paolo dot carlini at oracle dot com 2008-09-10 15:54
---
I have a patch in testing which changes -O3 to be the same as -O2, essentially
I moved _M_narrow_init and _M_widen_init out of line. For further tweaks,
really after 4.4.0.
--
http://gcc.gnu.org/bugzilla/s
--- Comment #5 from kargl at gcc dot gnu dot org 2008-09-10 15:42 ---
Daniel,
I looked at this briefly last week. Here's another test case that might be
easier to trace.
implicit none
real(4) r
real(8) rd
complex(8) z
rd =
dble(b'0100
--- Comment #6 from M dot Froehlich at science-computing dot de 2008-09-10
15:38 ---
(In reply to comment #5)
> Yes, but frankly it's unlikely that in 4.4.0 timeframe, also given the ABI
> constraints, we can change the libstdc++ implementation, which admittedly has
> too much code inli
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #7 from bangerth at dealii dot org 2008-09-10 15:30 ---
Still the same with gcc version 4.4.0 20080801 (experimental) [trunk revision
138448]
--
bangerth at dealii dot org changed:
What|Removed |Added
---
--- Comment #12 from bangerth at dealii dot org 2008-09-10 15:26 ---
Still happens with gcc version 4.4.0 20080801 (experimental) [trunk revision
138448]
--
bangerth at dealii dot org changed:
What|Removed |Added
---
--- Comment #5 from paolo dot carlini at oracle dot com 2008-09-10 15:23
---
Yes, but frankly it's unlikely that in 4.4.0 timeframe, also given the ABI
constraints, we can change the libstdc++ implementation, which admittedly has
too much code inline in this area, enough to solve this p
--- Comment #7 from jakub at gcc dot gnu dot org 2008-09-10 15:21 ---
If the whole testcase is supposed to be valid, we could have COND_EXPRs with
mismatching types in the FE and fix them up only during cp_genericize_r.
The ugly thing is that we'd violate:
Operand 1 must have the same
--- Comment #4 from paolo dot carlini at oracle dot com 2008-09-10 15:16
---
Gentoo, right?
Note that the issue definitely does not affect widespread linux distributions,
as you can see from the successful build / testing results posted daily on the
testresults mailing list.
*** This
--- Comment #31 from paolo dot carlini at oracle dot com 2008-09-10 15:16
---
*** Bug 37453 has been marked as a duplicate of this bug. ***
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #2 from bergner at gcc dot gnu dot org 2008-09-10 15:14 ---
With a mainline from today, it fails for me at -O2. Looking into it, it's
foo() that is miscompiled (I broke the 3 functions into their own files and
recompiled them), It's also the last element of results (ie, res
--- Comment #10 from tbm at cyrius dot com 2008-09-10 15:14 ---
Created an attachment (id=16287)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16287&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37333
--- Comment #4 from bergner at gcc dot gnu dot org 2008-09-10 15:14 ---
Sorry, ignore my Comment #3. It should have been posted to a different
bugzilla entry. :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
--- Comment #9 from tbm at cyrius dot com 2008-09-10 15:13 ---
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> Do you have a testcase for x86? The one in comment #1 works for me.
Sure:
(sid)2206:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-09-10 15:12 ---
Still happens.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2
--- Comment #6 from jakub at gcc dot gnu dot org 2008-09-10 15:11 ---
Created an attachment (id=16286)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16286&action=view)
a different patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37146
--- Comment #5 from jakub at gcc dot gnu dot org 2008-09-10 15:10 ---
I think primarily we want to agree on what is and is not valid lvalue when
bitfields are involved.
int a;
int b;
struct A { int i:8; int j:8; int k:16; int l:32; } c;
void
foo (int x, int y)
{
(x ? a : b) = y;
(x
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-09-10 15:10 ---
Fixed now.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-09-10 15:08 ---
Subject: Bug 37432
Author: rguenth
Date: Wed Sep 10 15:07:04 2008
New Revision: 140233
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140233
Log:
2008-09-10 Richard Guenther <[EMAIL PROTECTED]>
PR
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|dodji at gcc dot gnu dot org|unassigned at gcc dot gnu
|
--- Comment #1 from hjl dot tools at gmail dot com 2008-09-10 14:59 ---
Honza suggested that
---
This mostl likely mean that your glibc has slow memset implementation.
I saw similar drop on SPEC2000 GCC and Debian machines used by
compilation farm. I was told that FSF glibc was finally
--- Comment #8 from hjl dot tools at gmail dot com 2008-09-10 14:58 ---
(In reply to comment #7)
> (In reply to comment #6)
> > Please close if fixed
>
> The ICE is still there (as of revision 140229).
>
Do you have a testcase for x86? The one in comment #1 works for me.
--
http:
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-10 14:54 ---
I see the same problem with the program below:
implicit none
real, parameter :: r = 0.0
real(kind=8), parameter :: rd = real(b'&
&0100
--- Comment #4 from dodji at gcc dot gnu dot org 2008-09-10 14:50 ---
At PDF page 115, 5.16.6 (conditional operator), the standard says:
"Lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3)
standard conversions are performed on the second and third operands. Af
--- Comment #2 from spop at gcc dot gnu dot org 2008-09-10 14:48 ---
Subject: Bug 37388
Author: spop
Date: Wed Sep 10 14:46:35 2008
New Revision: 140232
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140232
Log:
2008-09-10 Sebastian Pop <[EMAIL PROTECTED]>
PR tree-opt
--- Comment #7 from tbm at cyrius dot com 2008-09-10 14:43 ---
(In reply to comment #6)
> Please close if fixed
The ICE is still there (as of revision 140229).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37333
Revision 140030 caused >10% 176.gcc performance regression
in SPEC CPU 2000 on Intel Core 2 running Linux/x86-64 with
-O2 -ffast-math.
--
Summary: [4..4 Regression] Revision 140030 caused >10% 176.gcc
regression
Product: gcc
Version: 4.4.0
--- Comment #9 from hjl dot tools at gmail dot com 2008-09-10 14:18 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from hjl at gcc dot gnu dot org 2008-09-10 14:15 ---
Subject: Bug 37434
Author: hjl
Date: Wed Sep 10 14:14:28 2008
New Revision: 140231
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140231
Log:
gcc/
2008-09-10 H.J. Lu <[EMAIL PROTECTED]>
PR target/374
--- Comment #74 from lucier at math dot purdue dot edu 2008-09-10 13:39
---
This need for more memory is a regression from earlier versions of gcc.
Can this bug be marked with
[4.3/4.4 Regression]
in the subject line?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #7 from salam at lpthe dot jussieu dot fr 2008-09-10 13:24
---
That's great. I've tested it with the latest binary snapshot and it works very
nicely.
Thanks a lot for fixing this!
Gavin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37199
--- Comment #3 from Gottfried dot Ganssauge at haufe dot de 2008-09-10
12:35 ---
The error doesn't happen anymore with gcc-4.3 - at least not with the original
source file.
I would propose to close this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31811
--- Comment #10 from pault at gcc dot gnu dot org 2008-09-10 12:33 ---
(In reply to comment #3
resolve.c(check_host_association) explicitly excludes checking the symbol for
the procedure if it is use associated. It might just be that the check should
exclude symbols that are both hos
--- Comment #9 from pault at gcc dot gnu dot org 2008-09-10 12:26 ---
(In reply to comment #3)
> reduced:
>
> MODULE M1
> INTERFACE putaline
> MODULE PROCEDURE S1,S2
> END INTERFACE
> CONTAINS
> SUBROUTINE S1(I)
> END SUBROUTINE
> SUBROUTINE S2(F)
> END SUBROUTINE
> END MODULE
>
--- Comment #2 from hubicka at gcc dot gnu dot org 2008-09-10 12:14 ---
The testcase no longer compiles on mainline for me because of syntax errors.
WOuld be possible to test newer compiler or have updated testcase?
Honza
--
hubicka at gcc dot gnu dot org changed:
What
--- Comment #7 from burnus at gcc dot gnu dot org 2008-09-10 12:09 ---
> Unfortunately, they got it wrong and are rejecting my claim that the
> test is standard conforming.
See also: http://www.j3-fortran.org/doc/year/08/08-104r1.txt
Let's mark it as "diagnostic". I think the error mes
--- Comment #8 from burnus at gcc dot gnu dot org 2008-09-10 11:55 ---
Subject: Bug 37420
Author: burnus
Date: Wed Sep 10 11:54:08 2008
New Revision: 140229
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140229
Log:
2008-09-10 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #7 from burnus at gcc dot gnu dot org 2008-09-10 11:54 ---
FIXED on the trunk (4.4.0)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tbm at cyrius dot com 2008-09-10 11:49 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */
struct nfs4_ace
{
unsigned int flag;
};
void _posix_to_nfsv4_one (struct nfs4_ace *ace, short deny, int flags)
{
int eflag = (flags ? (0x0001 | 0x0008) : 0);
--- Comment #1 from tbm at cyrius dot com 2008-09-10 11:49 ---
Created an attachment (id=16285)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16285&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37461
--- Comment #8 from hubicka at gcc dot gnu dot org 2008-09-10 11:39 ---
And at -O0 we still need about 2GB (because of dataflow leaks?), otherwise we
seem fine compilation time wise
garbage collection: 0.92 ( 3%) usr 0.00 ( 0%) sys 0.93 ( 3%) wall
0 kB ( 0%) ggc
callgra
--- Comment #8 from burnus at gcc dot gnu dot org 2008-09-10 11:33 ---
> actually, I rather sure that gfortran gets it wrong. This would be a
> wrong-code
Unless it were accepts-invalid. (Which I don't think, see below.)
Unfortunately, I yesterday somehow completely missed the second CO
1 - 100 of 132 matches
Mail list logo
