--- Comment #4 from spop at gcc dot gnu dot org 2009-12-18 07:56 ---
Still not fully fixed, I'm reducing another testcase that fails a bit later in
induct.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42180
--- Comment #3 from spop at gcc dot gnu dot org 2009-12-18 07:55 ---
Subject: Bug 42180
Author: spop
Date: Fri Dec 18 07:55:05 2009
New Revision: 155338
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155338
Log:
Fix PR42180.
2009-12-18 Sebastian Pop
PR middle-end/42
--- Comment #2 from spop at gcc dot gnu dot org 2009-12-18 07:43 ---
Reduced testcase:
module mcc_m
integer, parameter, private :: longreal = selected_real_kind(15,90)
contains
subroutine mutual_ind_cir_cir_coils (r1, r2, x12, y12, z12, l1, l2,
turns1, turns2, &
--- Comment #4 from spop at gcc dot gnu dot org 2009-12-18 07:38 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from spop at gcc dot gnu dot org 2009-12-18 07:38 ---
Subject: Bug 42135
Author: spop
Date: Fri Dec 18 07:38:06 2009
New Revision: 155337
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155337
Log:
Fix PR42135.
2009-12-18 Jack Howarth
PR testsuite/42135
--- Comment #1 from pault at gcc dot gnu dot org 2009-12-18 06:47 ---
This fixes it and even bootstraps and regtests:
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c (revision 155192)
+++ gcc/fortran/inte
--- Comment #4 from kargl at gcc dot gnu dot org 2009-12-18 06:43 ---
(In reply to comment #3)
> No,
>
> this was the trunk from yesterday. Some wrinkeles seem to remain...
>
You should have included this information in your
original bug report. I won't have wasted my time
looking u
--- Comment #1 from spop at gcc dot gnu dot org 2009-12-18 06:33 ---
Mine.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gc
--- Comment #2 from spop at gcc dot gnu dot org 2009-12-18 06:26 ---
Fixed in the Graphite branch.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from spop at gcc dot gnu dot org 2009-12-18 06:25 ---
Subject: Bug 42393
Author: spop
Date: Fri Dec 18 06:25:32 2009
New Revision: 155336
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155336
Log:
Fix PR42393.
2009-12-17 Sebastian Pop
PR middle-end/42
--- Comment #6 from spop at gcc dot gnu dot org 2009-12-18 06:19 ---
Fixed in the Graphite branch.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from spop at gcc dot gnu dot org 2009-12-18 06:19 ---
Subject: Bug 42186
Author: spop
Date: Fri Dec 18 06:18:51 2009
New Revision: 155335
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155335
Log:
Fix PR42186.
2009-12-17 Sebastian Pop
PR middle-end/42
--- Comment #4 from spop at gcc dot gnu dot org 2009-12-18 06:12 ---
Mine.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gc
--- Comment #8 from spop at gcc dot gnu dot org 2009-12-18 06:11 ---
Fixed in the Graphite branch. Will be committed to trunk after test.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from spop at gcc dot gnu dot org 2009-12-18 06:10 ---
Subject: Bug 42205
Author: spop
Date: Fri Dec 18 06:10:06 2009
New Revision: 155334
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155334
Log:
Fix PR42205.
2009-12-17 Sebastian Pop
PR middle-end/42
--- Comment #3 from jpr at csc dot fi 2009-12-18 05:43 ---
No,
this was the trunk from yesterday. Some wrinkeles seem to remain...
Juha
--
jpr at csc dot fi changed:
What|Removed |Added
---
--- Comment #6 from spop at gcc dot gnu dot org 2009-12-18 05:42 ---
Mine.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gc
--- Comment #5 from spop at gcc dot gnu dot org 2009-12-18 05:33 ---
Fixed in the Graphite branch. I will commit this to trunk once it passes usual
Graphite branch tests.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from spop at gcc dot gnu dot org 2009-12-18 05:31 ---
Subject: Bug 42221
Author: spop
Date: Fri Dec 18 05:30:56 2009
New Revision: 155333
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155333
Log:
Fix PR42221.
2009-12-17 Sebastian Pop
PR middle-end/42
--- Comment #1 from pault at gcc dot gnu dot org 2009-12-18 05:27 ---
I bumped this up to "accepts-invalid" to make it a bit more prominent. It is
even a correct designation because the "RHS too many items" is manifestly
invalid.
Cheers
Paul
--
pault at gcc dot gnu dot org change
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2009-12-18
05:14 ---
Committed revision 155211.
--
d dot g dot gorbachev at gmail dot com changed:
What|Removed |Added
-
We are getting the core dumps while trying to execute python-2.5.1 ctypes test
cases in 64-bit mode in AIX 5.3 using xlc compiler.
First we applied this patch
http://gcc.gnu.org/bugzilla/attachment.cgi?id=15274&action=diff to libffi-3.0.8
for the support of
64-bit libffi in AIX and we compiled the
--- Comment #1 from palmtag5 at yahoo dot com 2009-12-18 02:54 ---
Full example:
program test2
implicit none
integer :: imatr(20)
imatr=0
write (*,*) 'Enter 20 integer values:'
read (*,*) imatr
write (*,*) 'results:'
write (*,*) imatr
An error occurs when arrays are read from the input using list-directed
input that uses a repeat(*) before a record terminator (/).
The repeat is ignored.
For example, reading an integer array dimensioned 10
integer :: imatrx(10)
...
read (*,*) imatrx
will give the wrong results wh
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-12-18 01:24 ---
*** Bug 32805 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-12-18 01:24 ---
Close as a dup of bug 3885.
*** This bug has been marked as a duplicate of 3885 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-12-18 01:24 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-12-18 01:24 ---
*** Bug 11494 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-12-18 01:24 ---
Close as a dup of bug 3885.
*** This bug has been marked as a duplicate of 3885 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bradley at dunn dot org 2009-12-18 01:23 ---
Created an attachment (id=19342)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19342&action=view)
Preprocessed source file triggering the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42421
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-12-18 01:23 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-18 01:23 ---
*** This bug has been marked as a duplicate of 3885 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-12-18 01:23 ---
*** Bug 42421 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
When subtracting 0x1 from 0xE, the -0x1 is incorrectly parsed as a suffix.
Subtracting 0x1 from other hex constants works fine.
$ cat bug.c
int good = 0xD-0x1;
int bad = 0xE-0x1;
$ gcc -v -save-temps -c bug.c
Using built-in specs.
Target: i686-redhat-linux
Configured with: ../configure --prefix=
--- Comment #30 from paolo dot carlini at oracle dot com 2009-12-18 00:58
---
I agree. In general, however, I'm not sure how general the issue is, now that
concepts are gone. For example, consider the case of the various classification
functions (from C99): you can still find a PR filed
--- Comment #2 from kargl at gcc dot gnu dot org 2009-12-18 00:57 ---
This should have already been fixed by
2009-12-04 Janne Blomqvist
PR libfortran/40812
* libgfortran.h: typedef gfc_offset differently for MinGW.
* io/unix.h (struct stream): Change function
--- Comment #2 from redi at gcc dot gnu dot org 2009-12-18 00:42 ---
I suspect this is the same issue, as it also passes a null argument to
write_expression
$ cat ice.cc
template
auto f(T t) -> decltype(++t, 0)
{
++t;
return 0;
}
int main()
{
f((int*)0);
}
$ ~/gcc/4.x/bin/g
--- Comment #1 from jpr at csc dot fi 2009-12-18 00:35 ---
or rather this
Index: unix.c
===
--- unix.c (revision 155325)
+++ unix.c (working copy)
@@ -781,7 +781,11 @@
static stream *
fd_to_stream (int fd,
Program bigfile
open( 1,file='bigfile',position='append')
End program bigfile
fails if size of the bigfile is > 2GB. This is due to
the struct stat holding 32 bit st_size field in this
platform. The following fix worked for me
(libgfortran/io/...)
Index: unix.c
=
--- Comment #29 from redi at gcc dot gnu dot org 2009-12-18 00:15 ---
I think it might be worth opening an issue about these functions, it's far too
easy for them to cause problems and make the names "next" and "prev" unusable
for user functions:
// simplified version of and
namespace
--- Comment #1 from janis at gcc dot gnu dot org 2009-12-18 00:15 ---
Created an attachment (id=19341)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19341&action=view)
Minimized testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42419
GCC trunk gets a ICE when building SPEC CPU2000 test 254.gap with "-m64 -O2
-mcpu=power7 -mno-altivec -ftree-vectorize", as demonstrated by a rather large
minimized testcase that I'll attach to this PR.
elm3b149% /home/janis/tools/gcc-trunk-anonsvn/bin/gcc -c -m64 -O2 -mcpu=power7
-mno-altivec -ft
--- Comment #36 from howarth at nitro dot med dot uc dot edu 2009-12-17
23:30 ---
(In reply to comment #31)
> Interestingly gcc-4.4.2 with the proposed patch,
> http://gcc.gnu.org/ml/java/2009-12/msg00027.html, shows gcj crashing the same
> way as gcc trunk with the same patch
>
>
--- Comment #2 from burnus at gcc dot gnu dot org 2009-12-17 23:07 ---
I think that at the current result of gfortran is OK. However, I think a proper
way would to send an interpretation request as we did before (PR39997, PR
40264). The question seems to be whether it is valid at all and
--- Comment #11 from dfranke at gcc dot gnu dot org 2009-12-17 23:07
---
[Adding Paul as CC]
(In reply to comment #10)
> Would you be so kind as to follow this. It's been unconfirmed for 18 months.
> Is it a bug or not and will we or won't we fix it?
>
> I vote for a WONTFIX to be h
--- Comment #1 from burnus at gcc dot gnu dot org 2009-12-17 23:02 ---
The following program is also rejected, unless the marked line is
removed/comment out. At a glance, it looks OK - and ifort, NAG f95 and g95
accept it. The error message is:
print *, fun(enisoc, [0.0])
--- Comment #16 from mexas at bristol dot ac dot uk 2009-12-17 23:00
---
I just checked that gcc4.2.5 installs fine on ia64 FreeBSD 9.0 current, but
all newer versions fail to build. Is it possible/feasible to debug this
by comparing gcc42 and gcc43? Unfortunately it's beyond my skills,
(found when going through the link of PR
gfortran rejects the following program where "gen" is both a generic and a
specific procedure name as interface argument to PROCEDURE. I cannot find a
reason why it should be invalid and thus I think it is valid.
procedure(gen) :: f
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfir
GCC trunk gets a ICE when building SPEC CPU2000 test 173.applu and several
others with "-O2 -mvsx -mno-altivec -ftree-vectorize", as demonstrated by this
minimized testcase:
subroutine ssor
implicit real*8 (a-h,o-z)
parameter (iar = 60)
common/cgcon/ nx, ny, nz
common
GCC trunk gets a ICE when building SPEC CPU2000 test 177.mesa with "-O2 -mvsx
-mno-altivec -ftree-vectorize", as demonstrated by this minimized testcase:
void
gl_xform_normals_3fv (unsigned int n, float v[][3], const float m[16],
float u[][3], unsigned char normalize)
{
--- Comment #5 from toon at moene dot org 2009-12-17 21:58 ---
> (Even with a temporary file, other things can go wrong!)
Paul, you are right - I agree with FX, but forgot to reply.
Closing as WONTFIX is OK with me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33905
--- Comment #5 from spop at gcc dot gnu dot org 2009-12-17 21:57 ---
Subject: Bug 42334
Author: spop
Date: Thu Dec 17 21:57:29 2009
New Revision: 155326
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155326
Log:
Fix fall outs from Fix-PR42334.
2009-12-17 Sebastian Pop
--- Comment #6 from spop at gcc dot gnu dot org 2009-12-17 21:57 ---
Subject: Bug 42178
Author: spop
Date: Thu Dec 17 21:57:29 2009
New Revision: 155326
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155326
Log:
Fix fall outs from Fix-PR42334.
2009-12-17 Sebastian Pop
--- Comment #6 from anlauf at gmx dot de 2009-12-17 21:09 ---
Created an attachment (id=19340)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19340&action=view)
Extended demo code.
Here's a slightly extended sample of the code where the two
submitted patches still fail with the "am
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirm
--- Comment #5 from pault at gcc dot gnu dot org 2009-12-17 21:04 ---
(In reply to comment #4)
> (In reply to comment #3)
Gentlemen,
What is the word on this? A WONTFIX?
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39654
--- Comment #2 from pault at gcc dot gnu dot org 2009-12-17 21:02 ---
Hmmm! :-)
Since Cray pointers are non-standard, one might argue for undetermined
behaviour. However, logically, both pointer and pointee are symbols in the
modules and so should be use associated.
Therefore, I vote
--- Comment #11 from jakub at gcc dot gnu dot org 2009-12-17 20:57 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #12 from jakub at gcc dot gnu dot org 2009-12-17 20:56 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from pault at gcc dot gnu dot org 2009-12-17 20:54 ---
(In reply to comment #9)
> With the upcoming release of 4.5, I think it would be nice to fix/improve the
> translation related bugs now, i.e. this, PR38573 and PR40489.
>
> As I have no idea how to reproduce/check/wh
--- Comment #1 from pault at gcc dot gnu dot org 2009-12-17 20:51 ---
I believe that gfortran behaves correctly in all the testcases in this thread.
I have written to Bob Corbet to see if he agrees. The nub of the matter is
that a local declaration always has precedence over a host ass
--- Comment #1 from truedfx at gentoo dot org 2009-12-17 20:51 ---
And here's the generated assembly:
.file "test.cc"
.text
.align 2
.globl _ZN1A1fEv
.type _ZN1A1fEv, @function
_ZN1A1fEv:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi
test.cc:
class A {
void f();
}
void A::f() {
A::A();
}
g++ -c test.cc
/tmp/cciN3Byt.s: Assembler messages:
/tmp/cciN3Byt.s:18: Warning: missing operand; zero assumed
/tmp/cciN3Byt.s:18: Error: undefined symbol `_ZN1AC1Ev' in operation
/tmp/cciN3Byt.s:18: Error: undefined symbol `INTERNAL' in
gcc/Makefile.in contains the line
sed '/set tmpdir/ s|testsuite|$(TESTSUITEDIR)/$*|' \
< ../../site.exp > tmp-site.exp; \
which caused a large number of test failures because I had the testsuite in a
path that included the word "testsuite" which was erroneously expanded.
Be
--- Comment #4 from pault at gcc dot gnu dot org 2009-12-17 20:17 ---
I think that FX was right, since Toon has not responded in 6 months.
Entering a WONTFIX
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
with Text_IO;
procedure test1 is
task type T1 is
entry E1;
end T1;
task body T1 is
begin
Text_IO.Put_Line ("T1 started");
accept E1;
Text_IO.Put_Line ("T1 done");
end T1;
function f1 return T1 is
begin
return R : T1;
end f1;
procedure p2 (
--- Comment #4 from davek at gcc dot gnu dot org 2009-12-17 19:58 ---
(In reply to comment #2)
> Created an attachment (id=19339)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19339&action=view) [edit]
> updated patch to allow specification of -static-libstdc++ on the CL while
> ge
--- Comment #3 from developer at sandoe-acoustics dot co dot uk 2009-12-17
19:54 ---
the patch has been modified following the discussions in:
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00862.html
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00855.html
to re-write "-static-libstdc++"
--- Comment #1 from ludovic at ludovic-brenta dot org 2009-12-17 19:52
---
$ gnatmake pak1
gcc-4.4 -c pak1.ads
pak1.ads:5:25: expected type "T1'class" defined at line 2
pak1.ads:5:25: found type "T1" defined at line 2
pak1.ads:6:19: dynamically tagged expression not allowed
gnatmake: "p
package pak1 is
type T1 is tagged null record;
x1: T1;
x2: T1'class := x1;
x3: T1'class renames x1; --ERROR: (detected) T1'class vs T1
x4: T1 renames x2;--ERROR: (missed)T1 vs T1'class
end pak1;
$ gnatmake pak1
gcc-4.3 -c pak1.ads
pak1.ads:5:25: expected type "T1'class
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2009-12-17
19:51 ---
Created an attachment (id=19339)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19339&action=view)
updated patch to allow specification of -static-libstdc++ on the CL while
generating PCH
--
de
--- Comment #1 from ludovic at ludovic-brenta dot org 2009-12-17 19:47
---
RM 8.6(27)/2 is also relevant:
When a construct is one that requires that its expected type be a
single type in a given class, the type of the construct shall be
determinable solely from the context in w
package pak1 is
type T1 is new integer;
type T1_access is access all T1;
x1: aliased T1;
x2: T1 := x1'access.all;--ERROR: 4.1(8) (missed)
x3: T1_access := T1_access(x1'access); --ERROR: 4.6(6) (detected)
end pak1;
Gnat misses the error involving x1'access.all.
RM 3
--- Comment #1 from ludovic at ludovic-brenta dot org 2009-12-17 19:42
---
Fixed in 4.4; this PR only to document the the issue for users of previous
versions.
--
ludovic at ludovic-brenta dot org changed:
What|Removed |Added
-
pragma ada_83;
with text_io;
procedure test1 is
type T1 is record
str: string(1..10);
end record;
x1: T1 := (str => (others => 49)); --ERROR: 49 is not a character
begin
text_io.put_line(x1.str);
end test1;
$ gnatmake test1; ./test1
gcc-4.3 -c test1.adb
gnatbind -x test1.ali
g
--- Comment #10 from jakub at gcc dot gnu dot org 2009-12-17 19:32 ---
Subject: Bug 41679
Author: jakub
Date: Thu Dec 17 19:32:32 2009
New Revision: 155324
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155324
Log:
PR debug/41679
* var-tracking.c (count_uses): Co
--- Comment #9 from jakub at gcc dot gnu dot org 2009-12-17 19:32 ---
Subject: Bug 41679
Author: jakub
Date: Thu Dec 17 19:31:52 2009
New Revision: 155323
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155323
Log:
PR debug/41679
* var-tracking.c (use_type): Remov
--- Comment #8 from jakub at gcc dot gnu dot org 2009-12-17 19:31 ---
Subject: Bug 41679
Author: jakub
Date: Thu Dec 17 19:30:58 2009
New Revision: 155322
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155322
Log:
PR debug/41679
* var-tracking.c (add_stores): Avo
--- Comment #11 from jakub at gcc dot gnu dot org 2009-12-17 19:29 ---
Subject: Bug 42386
Author: jakub
Date: Thu Dec 17 19:29:48 2009
New Revision: 155321
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155321
Log:
PR c++/42386
* ipa.c (function_and_variable_visi
--- Comment #11 from dominiq at lps dot ens dot fr 2009-12-17 19:16 ---
> I tried to build gcc on darwin to debug this but the build fails with a link
> failure (sorry, don't remember exactly where). Do I need to do something
> special to build on darwin?
On which version of darwin did
--- Comment #10 from espindola at gcc dot gnu dot org 2009-12-17 18:09
---
I tried to build gcc on darwin to debug this but the build fails with a link
failure (sorry, don't remember exactly where). Do I need to do something
special to build on darwin?
The error message is emitted when
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-17 17:55
---
Yes, this is known, no need to keep this issue open for ongoing C++0x work: the
issue basically is that has not been un-conceptualized yet in the WP,
now that Concepts are gone, and we are for now keeping the
(This Bug follows 4205 which is not marked FIXED)
On armv5tel-unknown-linux-gnueabi I compiled gcj plus .../contrib/download_ecj.
Last Changed Rev: 155206
Last Changed Date: 2009-12-13 21:06:50 -0800 (Sun, 13 Dec 2009)
installed
There is no templatized user-provided seed()
and related constructors in the C++0x random
number generation library. The draft N3000 says
that the engines (Mersenne Twister, among others)
have
template explicit mersenne_twister_engine(Sseq& q);
template void seed(Sseq& q);
in order to use a user-
--- Comment #3 from hjl dot tools at gmail dot com 2009-12-17 17:27 ---
This is caused by new SRA:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00959.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42398
--- Comment #2 from jlpoole at pon dot net 2009-12-17 17:18 ---
Thank you. This worked:
export LD_LIBRARY_PATH=/usr/local/gcj/usr/local/lib
then
plug bin # ./gcj -v -I /usr/local/gcj/usr/local/share/java/libgcj-4.5.0.jar
/var
/work/gcj/HelloWorld.java
--
jlpoole at pon dot net cha
--- Comment #3 from bkoz at gcc dot gnu dot org 2009-12-17 17:04 ---
We really need something for gcc-4.5/porting_to.html
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
-
A potential source of error for C programmers is the inadvertent covering of
one header file by another with the same name. This issue is documented by
CERT in the "CERT C Secure Coding Standard" as "PRE08-C. Guarantee that header
file names are unique
[https://www.securecoding.cert.org/confluence
--- Comment #2 from hjl dot tools at gmail dot com 2009-12-17 16:38 ---
It is caused by revision 147995:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00974.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-17 16:25 ---
I'm not sure if arm has been updated for CFI in the prologue/epilogue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-17 16:22 ---
Documentation improvement is always welcome, especially if you looked for it
but
missed the critical piece.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42376
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-17 16:22 ---
Make sure your install library path is in LD_LIBRARY_PATH.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-17 16:20 ---
-Wunreachable-code is broken and has been removed in 4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from davek at gcc dot gnu dot org 2009-12-17 15:27 ---
Should be fixed in SVN now. Rainer, please verify when you get a chance.
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from davek at gcc dot gnu dot org 2009-12-17 15:25 ---
Subject: Bug 42377
Author: davek
Date: Thu Dec 17 15:25:36 2009
New Revision: 155318
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155318
Log:
PR target/42377
* config/abi/pre/gnu.ver: Adjust
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-17 15:17 ---
Btw, the single-file testcase
#include
#include
int main ()
{
typedef std::map Map;
static Map m;
Map::const_iterator it = m.find(0);
if (it != m.end()) {
std::string s = it->second;
}
}
fails t
gcc issues warning when using the tolower function along with an optimization
flag. This warning also happens in other versions of gcc apart from 4.4.2
gcc -std=c99 -pedantic -O2 -Wall -Wunreachable-code a.c
a.c:13: warning: will never be executed
#include
#include
#include
int main(void)
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-12-17 14:39 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-12-17 14:36 ---
Subject: Bug 42397
Author: rguenth
Date: Thu Dec 17 14:36:43 2009
New Revision: 155316
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155316
Log:
2009-12-17 Richard Guenther
PR middle-end/42397
1 - 100 of 155 matches
Mail list logo
