--- Comment #3 from dominiq at lps dot ens dot fr 2008-01-30 08:08 ---
> Did this happen with the 4.2.2 release?
I just checked on darwin9 and the answer is yes. Nevertheless could someone
have a look to the problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35012
--- Comment #2 from marco at sitek dot it 2008-01-30 08:43 ---
I do confirm that applying pr31388, gcc 4.2.2 build passes the mentioned bug.
thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34900
--- Comment #8 from steven at gcc dot gnu dot org 2008-01-30 09:10 ---
How did you configure gcc (i.e. command line)? What is the output if you
compile with -v?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-01-30 09:52
---
This is fixed in current trunk, the patch has been applied at some point.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keyw
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-01-30 10:04
---
(In reply to comment #4)
> Author: ktietz
> Date: Wed Jan 2 10:46:17 2008
> New Revision: 131255
Kai, did the patch fully fix the issue? If so, could you close this PR?
--
fxcoudert at gcc dot gnu dot org ch
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--
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 #9 from rguenth at gcc dot gnu dot org 2008-01-30 10:04 ---
Doesn't ICE with a x86_64->alpha-linux cross either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33410
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35023
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #2 from rsandifo at gcc dot gnu dot org 2008-01-30 11:19
---
Subject: Bug 34998
Author: rsandifo
Date: Wed Jan 30 11:18:27 2008
New Revision: 131960
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131960
Log:
gcc/
PR rtl-optimization/34998
* global.c
--- Comment #6 from ktietz at gcc dot gnu dot org 2008-01-30 11:34 ---
The issue is solved.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #10 from tbm at cyrius dot com 2008-01-30 11:34 ---
(In reply to comment #8)
> How did you configure gcc (i.e. command line)? What is the output if you
> compile with -v?
Configured with: ../src/configure -v --with-pkgversion='Debian 20080113-1'
--with-bugurl=file:///usr/s
--- Comment #3 from rsandifo at gcc dot gnu dot org 2008-01-30 11:36
---
Patch applied. Thanks to Ian and Kenny for the reviews.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from tammer at tammer dot net 2008-01-30 12:34 ---
Hello,
I think this is the location where the first failure occurs:
/opt/freeware/bin/bash ../libtool --tag CXX --tag disable-shared --mode=compile
/opt/freeware/src/packages/BUILD/
gcc-build/./gcc/xgcc -shared-libgcc
-B/
--- Comment #14 from steven at gcc dot gnu dot org 2008-01-30 12:35 ---
Patch in comment #9 works for me.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tammer at tammer dot net 2008-01-30 12:30 ---
Created an attachment (id=15056)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15056&action=view)
gcc 4.3 build log
Interesing part starts at: line 17385
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35029
Hello,
I have a problem bootstrapping gcc 4.3 HEAD with gcc 4.3 HEAD...
The failure occurs in: Comparing stages 2 and 3
Please see the attached file.
It looks if the compiler has a problem with -prefer-pic
I have first build gcc 4.3 HEAD with gcc 4.2.2 (from www.perzl.org / AIX 5.3
build) and n
--- Comment #8 from bonzini at gnu dot org 2008-01-30 13:37 ---
Subject: Bug 34922
Author: bonzini
Date: Wed Jan 30 13:36:35 2008
New Revision: 131961
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131961
Log:
2008-01-30 Ralf Wildenhues <[EMAIL PROTECTED]>
PR bootstra
--- Comment #13 from dominiq at lps dot ens dot fr 2008-01-30 14:16 ---
I have applied the patch on top of rev. 131960 on i686-apple-darwin9. The only
change I have noticed is that the ICE for he code in comment #10 has been
replaced by the following (cryptic) error:
pr34828_1.f90:6.80:
--- Comment #4 from hjl at gcc dot gnu dot org 2008-01-30 14:37 ---
Subject: Bug 34612
Author: hjl
Date: Wed Jan 30 14:36:58 2008
New Revision: 131964
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131964
Log:
2008-01-30 H.J. Lu <[EMAIL PROTECTED]>
PR libffi/34612
As done for actual and formal arguments in functions/subroutines (e.g.
PR34901), the error messages for pointer assignments could be improved:
E,g,
neighbours_neighbours => dummy_atom_kdtree_region_search(this%beads, at
1
Error: Different types in pointer assign
--- Comment #15 from hubicka at gcc dot gnu dot org 2008-01-30 15:54
---
Fixed at mainline. I am really surprises this is 4.3 only regression since the
code didn't see much changes in last few releases.
--
hubicka at gcc dot gnu dot org changed:
What|Removed
--- Comment #16 from hubicka at gcc dot gnu dot org 2008-01-30 15:55
---
Subject: Bug 34982
Author: hubicka
Date: Wed Jan 30 15:54:14 2008
New Revision: 131966
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131966
Log:
PR target/34982
* i386.c (init_cumulative_
--- Comment #17 from hubicka at ucw dot cz 2008-01-30 15:56 ---
Subject: Re: [4.3 regression] calling a function with undefined parameters
causes segmentation fault at -O1 or higher
> These tests time out from time to time when the testing box is busy, that's
> quite
> normal. The pro
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-01-30 16:00 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
ELEMENTAL conflicts with BIND(C).
However, the following is not rejected (diagnosed) by gfortran:
elemental subroutine sub(x)
integer, intent(in) :: x
entry sub_c(x) bind(c)
end subroutine sub
Actually, this is a loop hole in the Fortran 2003 standard, which will be
presumably fi
--- Comment #9 from bonzini at gnu dot org 2008-01-30 16:21 ---
patch committed.
--
bonzini at gnu dot org changed:
What|Removed |Added
CC|
--- Comment #11 from hubicka at gcc dot gnu dot org 2008-01-30 16:04
---
If you have nothing against, I would probably go for -mfpmath=sse implied by
-ftree-vectorize route then.
Since there is now i386 ABI mailing list I hope if we can move in direction of
having -mfpmath=sse by defau
>From Fri Jan 25 06:57:52 UTC 2008 (revision 131816)
Configured thusly:
../trunk/configure --with-arch=r5000 --disable-java-awt --without-x
--enable-__cxa_atexit --disable-jvmpi --disable-libgomp --disable-static
--enable-languages=c,c++,java --disable-fixed-point --enable-checking=release
--with
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-01-30 16:58 ---
The ice-on-valid is not a regression though (it only happens with -std=c++0x
which is new). P4 again.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
To my understanding, the interface declaration is valid (Fortran 2003, ignoring
VOLATILE valid Fortran 95). However, gfortran rejects it with:
END SUBROUTINE
1
Error: Assignment operator interface at (1) must not redefine an INTRINSIC type
assignment
NAG f95
--- Comment #34 from hubicka at gcc dot gnu dot org 2008-01-30 17:13
---
[EMAIL PROTECTED]:/aux/hubicka/trunk-write/buidl2$ time ./test-3.4
real0m5.692s
user0m5.588s
sys 0m0.012s
[EMAIL PROTECTED]:/aux/hubicka/trunk-write/buidl2$ time ./test-3.4
real0m5.536s
user0m
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-30 17:22 ---
"Error: Assignment operator interface at (1) must not redefine an INTRINSIC
type
assignment"
The error message by itself is correct - but
a) The position is very bad it should point to SUBROUTINE and not to END
SUBRO
--- Comment #7 from bcbarnes at gmail dot com 2008-01-30 17:18 ---
This bug also shows up when executing the example code for initializing
random_seed in the gfortran documentation. Is it a regression w.r.t. 4.0 or
4.1? Maybe not, but it would be nice if something in the docs didn't g
--- Comment #25 from ebotcazou at gcc dot gnu dot org 2008-01-30 17:33
---
> Bootstrap is unbroken, lowering severity.
What did you mean exactly here? :-) Severity is still "blocker".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-01-30 17:35
---
> This should be P1 on the 4.1 branch (at it is a regression on the branch), but
> we don't have separate priorities there and there will be no future releases
> from that branch.
This is still "critical" on the
--- Comment #35 from hubicka at gcc dot gnu dot org 2008-01-30 17:58
---
So for more proper analysis. The testcase is quite challenging for inlining
heuristics and by introducing early inlining and reducing call cost we now
inline less that we used to at a time I claimed that we inline
--- Comment #14 from Jerry_V_DeLisle at rl dot gov 2008-01-30 18:04 ---
The pr19925 segfault is close by the segfault here but not the same. I am
working on a patch for that one. What is becoming clear is that we are not
handling expansion of constructors very well yet.
Also, I will a
--- Comment #36 from hubicka at gcc dot gnu dot org 2008-01-30 18:14
---
Looking at the .optimized dump, one obvious problem is that we keep a lot of
pointer arithmetic that should be forward propagated:
:;
D.184420 = *pz;
p1 = pz + 8;
D.184422 = *p1;
p1 = p1 + 8;
D.184424 = *
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-30 18:25 ---
Created an attachment (id=15057)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15057&action=view)
Draft Patch
First patch:
- Better error message
- Fix that check
But ...
The volatile constrain is properly tak
--- Comment #1 from lennox at cs dot columbia dot edu 2008-01-30 18:26
---
The static const data problem is also PR 35017, now fixed; I'm editing the
summary accordingly.
The problem with static inline functions is not restricted to Darwin. The
following example shows the problem on a
--- Comment #2 from lennox at cs dot columbia dot edu 2008-01-30 18:28
---
Created an attachment (id=15058)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15058&action=view)
test program illustrating the warning about static inline functions, using
emmintrin.h
--
http://gcc.gn
--- Comment #11 from belyshev at depni dot sinp dot msu dot ru 2008-01-30
18:33 ---
Reconfirmed using amd64->alpha cross r131966:
f.c:9: internal compiler error: in iv_analyze_expr, at loop-iv.c:936
Note: gcc was configured with: --with-long-double-128
--target=alpha-unknown-linux-gnu
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #8 from kargl at gcc dot gnu dot org 2008-01-30 19:26 ---
(In reply to comment #7)
> This bug also shows up when executing the example code for initializing
> random_seed in the gfortran documentation. Is it a regression w.r.t. 4.0 or
> 4.1? Maybe not, but it would be nice
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-01-30 19:34 ---
$> gfortran-svn -g -Wall -c pr34897.f90
pr34897.f90:1.6:
function my_string(x)
1
Warning: Return value of function 'my_string' at (1) not set
No valgrind errors either. Magically fixed?
--
http://gc
--- Comment #60 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-30
19:44 ---
Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in
find_new_var_of_type, at ipa-struct-reorg.c:605
> > On hppa2.0w-hp-hpux11.11, we are down to:
> Dave,
>
> Can you please try this patch:
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot
|dot org
--- Comment #9 from manu at gcc dot gnu dot org 2008-01-30 19:53 ---
I tried this:
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c (revision 131893)
+++ gcc/fortran/trans-array.c (working copy)
@@ -12
--- Comment #7 from dfranke at gcc dot gnu dot org 2008-01-30 20:27 ---
*** Bug 34897 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34990
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-01-30 20:27 ---
*** This bug has been marked as a duplicate of 34990 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from bangerth at dealii dot org 2008-01-30 20:26 ---
I agree. This is valid and common code and we need to be able to compile it.
I would rate this as a blocker.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
-
--- Comment #10 from manu at gcc dot gnu dot org 2008-01-30 20:13 ---
For my classification of -Wuninitialized problems (see
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings), this is caused by a
representation issue.
--
manu at gcc dot gnu dot org changed:
What|
--- Comment #37 from stevenb dot gcc at gmail dot com 2008-01-30 20:13
---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] performance loss (not inlining as
much??)
> Those seems to be all just array manipulations.
AFAICT, they are exactly in the form that some targets like it (e.g.
auto-i
--- Comment #9 from mmitchel at gcc dot gnu dot org 2008-01-30 20:40
---
I agree that this is P1..
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dominiq at lps dot ens dot fr 2008-01-30 21:54 ---
libffi is even more broken on powerpc-apple-darwin9 than on
powerpc-apple-darwin8:
=== libffi Summary for unix/-m64 ===
# of expected passes412
# of unexpected failures412
# of un
--- Comment #8 from dfranke at gcc dot gnu dot org 2008-01-30 22:22 ---
> Not actively. It's probably not so hard, though: read the file, like we
> do with -fsyntax-only mode, and parse #file headers.
FX, I'm lost here. The flag_syntax_only is not used anywhere in the fortran
directory
4.3.0 20080130
(experimental) (GCC) testsuite on powerpc-apple-darwin8.5.0)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35035
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-30 22:29 ---
Created an attachment (id=15059)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15059&action=view)
Patch - build & regtested (x86-64-linux)
Patch fixes actual problem and includes a test case. Missing is only im
--- Comment #2 from manu at gcc dot gnu dot org 2008-01-30 22:30 ---
(In reply to comment #1)
> See also: PR29458
Why? Those two bugs have nothing to do with each other.
BTW, how can a conversion from INTEGER(4) to INTEGER(8) change a value? I think
the Wconversion warning is wrong, no
There seem to be different, conflicting implementations of
size_of_encoded_value():
dwarf2asm.c-int
dwarf2asm.c:size_of_encoded_value (int encoding)
unwind-pe.h-static unsigned int
unwind-pe.h:size_of_encoded_value (unsigned char encoding)
/scratch/obj.i686/gcc-4.3/./gcc/xgcc -B/scratch/obj.i68
So far I have been unable to run the libjava test suite on
powerpc-apple-darwin9: after some (short?) time I lose any access to my machine
and I have to reboot. The faulty test seems random:
run 1 (rev. 130708):
...
PASS: register2.c compilation
set_ld_library_path_env_vars:
ld_library_path=.:/op
--- Comment #6 from burnus at gcc dot gnu dot org 2008-01-30 22:14 ---
Paul's patch with and added if condition (see below) nicely compiles all
examples + regtests; however, the example of comment 2 gives a wrong result
("< >" instead of "< 1 2 3 >") [this is independent of the patch]. F
--- Comment #2 from andreast at gcc dot gnu dot org 2008-01-30 22:18
---
This should help you:
http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01465.html
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pault at gcc dot gnu dot org 2008-01-30 22:42 ---
(In reply to comment #0)
> Problem seems to be in expr.c (gfc_check_assign):2690. If the containing
> namespace is a function, the appropriate tests are skipped.
This is regtesting right now:
Index: gcc/fortran/expr
--- Comment #1 from aldot at gcc dot gnu dot org 2008-01-30 22:56 ---
Works with -O2, fails with -O0, -O1, -O2 -fno-inline
-O0:
$ /scratch/obj.i686/gcc-4.3/./gcc/xgcc -B/scratch/obj.i686/gcc-4.3/./gcc/
-B/opt/i686/gcc-4.3//i686-linux-gnu/bin/
-B/opt/i686/gcc-4.3//i686-linux-gnu/lib/ -is
--- Comment #18 from dominiq at lps dot ens dot fr 2008-01-30 22:59 ---
On i686-apple-darwin9 (rev. 131968), the new test
gcc.c-torture/execute/pr34982.c fails:
FAIL: gcc.c-torture/execute/pr34982.c execution, -O1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
--- Comment #20 from pinskia at gcc dot gnu dot org 2008-01-30 23:08
---
(In reply to comment #19)
> Any idea why the test is failing in the test suite?
Yes because main needs a "return 0;"
so the main function should look like:
int main()
{
something(-1);
return 0;
}
--
http
--- Comment #22 from pinskia at gcc dot gnu dot org 2008-01-30 23:18
---
(In reply to comment #21)
> but why does this happen only with -O1?
Random value in eax register so we could put 0 in some cases but not others.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
--- Comment #38 from hubicka at ucw dot cz 2008-01-30 23:19 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] performance loss (not inlining as
much??)
> AFAICT, they are exactly in the form that some targets like it (e.g.
> auto-inc/dec and SMALL_REGISTER_CLASS targets).
Yep, but all the
--- Comment #23 from hubicka at ucw dot cz 2008-01-30 23:20 ---
Subject: Re: [4.3 regression] calling a function with undefined parameters
causes segmentation fault at -O1 or higher
> (In reply to comment #21)
> > but why does this happen only with -O1?
>
> Random value in eax registe
--- Comment #21 from dominiq at lps dot ens dot fr 2008-01-30 23:15 ---
> Yes because main needs a "return 0;"
but why does this happen only with -O1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
--- Comment #19 from dominiq at lps dot ens dot fr 2008-01-30 23:05 ---
Follow up to comment #18, the test pass if I run it directly or if I run
gcc/testsuite/gcc/pr34982.x1.
Any idea why the test is failing in the test suite?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34982
--- Comment #2 from rth at gcc dot gnu dot org 2008-01-31 00:06 ---
Subject: Bug 34993
Author: rth
Date: Thu Jan 31 00:05:19 2008
New Revision: 131970
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131970
Log:
PR c/34993
* tree.c (build_type_attribute_qual_varian
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2008-01-31 00:26
---
(In reply to comment #8)
> As I see it, gfortran never knows it does syntax checking only?!
Exactly.
> What exactly do you mean by "#file headers"? Preprocessor include directives
> as
> `#include "foo.inc"`?
"E8.0" is an illegal format descriptor, but g77 produces a wrong output
"0.1+01" for a value of 1e5, instead of a more sensible "" .
$ cat tmp.f
a = 1.e5
write(*,'(E8.0)') a
end
$ g77 --version
GNU Fortran (GCC) 3.4.6 (Debian 3.4.6-6)
[. . .]
$ g77 tmp.f
$ ./a.out
0.1+0
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-31 01:29 ---
Hmm, gfortran produces something slightly different:
[dhcp-10-98-10-23:~] apinski% ~/local-gcc/bin/gfortran t.f -pedantic
[dhcp-10-98-10-23:~] apinski% ./a.out
0.E+01
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #1 from manu at gcc dot gnu dot org 2008-01-31 01:32 ---
I am not sure if this is actually a bug, since I think functions with weak
linkage can actually have a null-address if they are not instantiated.
Nonetheless, a regression hunt identifies this patch as the cause:
r1041
--- Comment #2 from kargl at gcc dot gnu dot org 2008-01-31 01:46 ---
(In reply to comment #0)
> "E8.0" is an illegal format descriptor,
Can you cite from the Fortran 95 standard why this is illegal?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35036
--- Comment #3 from furue at hawaii dot edu 2008-01-31 02:00 ---
Subject: Re: illegal E format descriptor produces wrong
output
Hi,
| --- Comment #2 from kargl at gcc dot gnu dot org 2008-01-31 01:46
---
| (In reply to comment #0)
| > "E8.0" is an illegal format descriptor,
--- Comment #4 from kargl at gcc dot gnu dot org 2008-01-31 02:24 ---
(In reply to comment #3)
> Subject: Re: illegal E format descriptor produces wrong
> output
>
> Hi,
>
> | --- Comment #2 from kargl at gcc dot gnu dot org 2008-01-31 01:46
> ---
> | (In reply to comment #0
--- Comment #5 from furue at hawaii dot edu 2008-01-31 02:45 ---
Subject: Re: illegal E format descriptor produces wrong
output
| There is no restriction in F95 that d must be positive in Ew.d.
| In 10.6.5.1, it clearly states that k = 0 at the beginning of
| execution of an input/ou
The following code demonstrates that when optimization is turned on, the memory
reference is being moved out of the loop. Thus, the volatile attribute is not
being honored.
As a workaround (and perhaps better solution), the user could use a module
instead of a common block. Gfortran works ok in
--- Comment #1 from w6ws at earthlink dot net 2008-01-31 03:09 ---
Adding myself to the cc list.
--
w6ws at earthlink dot net changed:
What|Removed |Added
--- Comment #6 from kargl at gcc dot gnu dot org 2008-01-31 04:09 ---
(In reply to comment #5)
> Subject: Re: illegal E format descriptor produces wrong
> output
>
> | There is no restriction in F95 that d must be positive in Ew.d.
> | In 10.6.5.1, it clearly states that k = 0 at the
I am using gcc 4.1.1 on CentOS.
PerfStatsCli.o(.text+0x26a6): In function `global constructors keyed to
0_main':
/home/nanda/galaxy/tsunami/PerfStats/cli/PerfStatsCli.cpp:664: undefined
reference to `__gcov_init'
PerfStatsCli.o(.data.rel+0x48): undefined reference to `__gcov_merge_add'
collect2: l
--- Comment #1 from nanda dot anni at wipro dot com 2008-01-31 04:47
---
I am unable to proceed further to get the code coverage for my application
(product).
Hence it is critical to fix this issue.
I had posted a query to gcov maintainers but their response was that, there
might be a b
--- Comment #5 from hp at gcc dot gnu dot org 2008-01-31 05:08 ---
The bug is that fwprop1 adds a REG_EQUAL note to an insn with a REG_RETVAL,
confusing delete_trivially_dead_insns into thinking that the REG_EQUAL note
refers to the while libcall and that a simplification thereof can mak
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2008-01-31 05:45
---
I will have to study the Standard some more as well. Off the top of my head I
have a vague recollection of working a bug like this before and we fixed it. I
will check into this.
--
jvdelisle at gcc dot gnu
--- Comment #8 from furue at hawaii dot edu 2008-01-31 06:16 ---
Subject: Re: illegal E format descriptor produces wrong
output
| > I may be missing something, but "-d < k <= 0" doesn't hold
| > when d = 0 and k = 0. Notice the inequality "<". So, when k = 0,
| > how should we read
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-01-31 06:27
---
Sun f95 gives:
** FORTRAN RUN-TIME SYSTEM **
Error 1078: scale factor out of range
Location: the WRITE statement at line 2 of "pr35036.f"
Unit: *
File: standard output
Aborted
ifort gives:
$ i
--- Comment #2 from mw268 at bath dot ac dot uk 2008-01-31 06:38 ---
(In reply to comment #1)
> This is working as designed. Why are you doing #include inside a namespace
> anyways?
>
I was using it to enclose windows.h in a namespace win to avoid potential
problems and ended up causi
bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions
But fixed in: mips64-linux-gcc (GCC) 4.3.0 20080130 (experimental) [trunk
revision 131970]
--
daney at gcc dot gnu dot org changed:
What|Removed
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35032
99 matches
Mail list logo
