--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-23 07:19 ---
Also note that GCC 4.1.x (nor 4.2.x) is not maintained any longer upstream,
so this bugreport would be only useful here if you can reproduce it with
vanilla
4.3.x or later.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #2 from ramu dot konaparthi at gmail dot com 2009-04-23 07:53
---
(In reply to comment #1)
> How is the libraries build? While linking do you use -fprofile-arcs
> -ftest-coverage?
>
Hello,
Thanks for your response.
Used options "-Wall -fprofile-arcs -ftest-coverage" fo
--- Comment #2 from dennis dot wassel at googlemail dot com 2009-04-23
08:27 ---
I tried the following things:
- #define SSIZE_MAX in host-linux.c as SHRT_MAX instead of LONG_MAX (as
suggested by an internal posix header on my system), to no avail.
- Just issue plain `make', instead of
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-23 08:45 ---
Simplified testcase (ICEs with both C and C++ FEs):
extern double pow (double, double);
extern double fabs (double);
void foo (double *);
void bar (double *);
static double
baz (double x, double e)
{
if ((int) e ==
--- Comment #4 from jakub at gcc dot gnu dot org 2009-04-23 08:50 ---
Even more reduced:
extern double pow (double, double);
extern double fabs (double);
void foo (double *);
static double
bar (double x, double e)
{
if ((int) e == 1)
return x;
return pow (x, e);
}
void
test (d
I just tried to compile the Suse Linux package openmcu-2.2.0-232.75
with the GNU g++ version 4.5 snapshot 20090416.
The compiler said
/home/dcb/gcc/20090416/results/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/stl_pair.h:68:
error: Wrong prev_try pointer in EH region
--- Comment #5 from jakub at gcc dot gnu dot org 2009-04-23 09:13 ---
I guess this is related to the (sometimes) uninitialized r variable (the same
as in the original povray sources).
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from doko at ubuntu dot com 2009-04-23 09:14 ---
turned out, that a wrong newlib build for spu was used. closing as invalid.
--
doko at ubuntu dot com changed:
What|Removed |Added
-
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywo
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-23 09:34 ---
tree memory partitioning: 51.43 (20%) usr 0.26 ( 9%) sys 51.80 (20%) wall
19 kB ( 0%) ggc
tree operand scan : 149.30 (58%) usr 1.20 (43%) sys 151.17 (57%) wall
18536 kB ( 4%) ggc
4.4 uses
tree m
--- Comment #22 from rguenth at gcc dot gnu dot org 2009-04-23 09:34
---
*** Bug 39860 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from dennis dot wassel at googlemail dot com 2009-04-23
09:54 ---
Tried to build using the all-in-one gcc-4.4.0 package (I only downloaded -core,
-g++ and -fortran before, all of which passed the md5 check) - still the same.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #1 from debian-gcc at lists dot debian dot org 2009-04-23
10:00 ---
invalid, build issue on Debian's side. sorry for the noise.
Matthias
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #1 from dcb314 at hotmail dot com 2009-04-23 09:02 ---
Created an attachment (id=17683)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17683&action=view)
gzipped C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39862
--- Comment #22 from aph at gcc dot gnu dot org 2009-04-23 11:08 ---
Re named register variables:
You can, instead of using
[coeff_ptr_l1] "+r" (coeff_ptr_l1)
declare something like
register long double *coeff_ptr_l1 asm ("%%r8");
and then use "%%r8" in your asm. This means that yo
--- Comment #9 from dodji at gcc dot gnu dot org 2009-04-23 11:14 ---
Subject: Bug 38228
Author: dodji
Date: Thu Apr 23 11:13:57 2009
New Revision: 146645
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146645
Log:
2009-04-23 Dodji Seketeli
gcc/cp/ChangeLog:
PR c+
--- Comment #10 from dodji at gcc dot gnu dot org 2009-04-23 11:15 ---
Subject: Bug 38228
Author: dodji
Date: Thu Apr 23 11:15:33 2009
New Revision: 146646
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146646
Log:
gcc/cp/ChangeLog:
PR c++/38228
* pt.c (unify
--- Comment #1 from pault at gcc dot gnu dot org 2009-04-23 11:10 ---
(In reply to comment #0)
Hi Dominique,
Could I ask a Bear-of-Little-Brain question here?
> write_symbol(): bad module symbol 'x'
Where does the symbol 'x' come from?
Cheers
Paul
--
http://gcc.gnu.org/bugzill
--- Comment #2 from dominiq at lps dot ens dot fr 2009-04-23 11:25 ---
> Where does the symbol 'x' come from?
Good question! The code generate a file vector_calculus.mod0 containing:
GFORTRAN module version '0' created from pr36192_mod_red.f90 on Thu Apr 23
13:17:45 2009
MD5:00
The following code :
==
template
struct A {};
template
struct S {};
template
A< S... > f(U... u)
{ return A< S... >(); }
int main()
{
f(0.0);
}
compiled with g++ -std=c++0x on today's trunk, produces :
test_
When I attempt to compile the following function using
http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/gcc-trunk-x86_64.tar.gz
FUNCTION next_state()
INTRINSIC :: RESHAPE
INTEGER, PARAMETER :: trantb(1,1) = RESHAPE((/1,2/), shape=(/1,1/))
next_state = trantb(1, 1)
END FUNCTION next_state
I get
--- Comment #3 from janus at gcc dot gnu dot org 2009-04-23 12:24 ---
> > write_symbol(): bad module symbol 'x'
>
> Where does the symbol 'x' come from?
The 'x' here apparently is the formal argument of the sqrt() function!
I think Dominique was right in suspecting my r146554, which
module mod
type t
real :: v(50)
end type t
type (t), target, allocatable :: v1(:)
integer :: v2, v3, v4
character(len=8), target, allocatable :: v5(:)
end module mod
subroutine test
use mod
integer :: i
write (*,v5(1:v3)) (v1(i)%v(v2), i=2, v4)
end subroutine test
ICEs in gfc_
--- Comment #1 from jakub at gcc dot gnu dot org 2009-04-23 12:47 ---
Actually, module isn't needed for the ICE:
subroutine test (v1, v2, v3, v4)
integer, target, allocatable :: v1(:)
character(len=8), target, allocatable :: v2(:)
integer :: v3, v4, v5
write (*,v2(1:v3)) (v1(i),
--- Comment #1 from burnus at gcc dot gnu dot org 2009-04-23 12:49 ---
Janus, can you have a look? It looks like another fallout of your patch. If it
is not fixable quickly, we should consider backing it out until we have a
working version.
--
burnus at gcc dot gnu dot org changed:
The following program :
=
struct A {
A& operator=(const A&) = delete;
void operator=(int) {}
void operator=(char) {}
};
struct B {};
int main()
{
A a;
a = B(); // no match
a = 1.0; // ambiguous
}
--- Comment #2 from dominiq at lps dot ens dot fr 2009-04-23 13:07 ---
This may be a stupid question, but are the codes in comments #0 and #1 valid?
The allocatable variables are used without being allocated, isn't it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39865
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-23 13:18 ---
Whether this is valid or not I have no idea.
Just bear in mind that this is a distilled compile time testcase, not intended
as runtime testcase, for runtime testcase obviously something would need to
allocate the alloc
--- Comment #4 from jakub at gcc dot gnu dot org 2009-04-23 13:33 ---
allocatable and target attributes aren't needed btw, the following ICEs as
well:
subroutine test (v1, v2, v3, v4)
integer :: v1(:)
character(len=8) :: v2(:)
integer :: v3, v4, v5
write (*,v2(1:v3)) (v1(i), v5=2
With GCC 4.4.0, the following program outputs 4294967295 instead of 2:
#include
int main (void)
{
int exp = -1;
printf ("%u\n", exp < 2 ? 2U : (unsigned int) exp);
return 0;
}
Note: I've tried with gcc-snapshot under a Debian/unstable x86_64 Linux
machine, but the same bug was reported to
trying to install the libstdc++ manpages for 4.4 in the same location as the
pages from the manpages-dev package, I see the following conflicts:
random.3 string.3 queue.3 ctime.3 regex.3
So maybe install all man pages as .3cxx?
Maybe don't install the todo.3 at all.
--
Summary: lib
--- Comment #2 from hjl dot tools at gmail dot com 2009-04-23 13:40 ---
Revision 145800 is good and revision 145813 is bad. It may be caused by
revision 145805:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00428.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39862
--- Comment #1 from vincent at vinc17 dot org 2009-04-23 13:44 ---
I forgot to say: the bug occurs whether one compiles with optimizations or not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39867
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-23 13:46 ---
We fold it to
return (int) MAX_EXPR <(unsigned int) exp, 2>;
which is obviously bogus. 4.3 produced
return NON_LVALUE_EXPR >;
which is correct (well, but has likely mismatched types if the 2 is still
unsigne
--- Comment #5 from jakub at gcc dot gnu dot org 2009-04-23 13:50 ---
subroutine test (v)
character(len=8) :: v(:)
write (*, v) 3
write (*, v(:)) 3
write (*, v(1:size (v))) 3
end subroutine test
ICEs too (on the second or third write stmt).
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #6 from burnus at gcc dot gnu dot org 2009-04-23 13:57 ---
Shorter, but gives not an error message but simply segfaults. (By the way, for
all tests I tried, gfortran 4.1 to 4.4 crashes, i.e. it is no regression.)
Seemingly, no one had tried before to pass an array to the FMT
--- Comment #7 from jakub at gcc dot gnu dot org 2009-04-23 14:19 ---
Well, gfc_convert_array_to_string seems to handle AR_FULL arrays correctly, but
probably just the other arrays does not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39865
--- Comment #9 from jv244 at cam dot ac dot uk 2009-04-23 14:21 ---
(In reply to comment #8)
> Having a shot at backporting, assigning to myself.
>
BTW, I only care about a backport to 4.4, which should be relatively easy.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39782
--- Comment #20 from laurent at guerby dot net 2009-04-23 14:24 ---
binutils from CVS 20090423 successfully link stage1 cc1 without any special
option (no --enable-checking-release and no -O1), my build on gcc55 is
currently in stage3
$ ../trunk/configure --prefix=/n/55/guerby/install
--- Comment #9 from bonzini at gnu dot org 2009-04-23 14:37 ---
(From update of attachment 17675)
The testcase includes an invalid asm (it should clobber memory).
--
bonzini at gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from jakub at gcc dot gnu dot org 2009-04-23 14:51 ---
A different testcase that segfaults even a little bit earlier:
subroutine test()
interface
function f()
character(len=1) :: f(5)
end function f
end interface
write (*, f()) 1
end subroutine test
He
--
bonzini at gnu dot org changed:
What|Removed |Added
Summary|[4.4 Regression] Wrong |[4.4/4.5 Regression] Wrong
|result of conditional |re
--- Comment #3 from bonzini at gnu dot org 2009-04-23 15:22 ---
Created an attachment (id=17684)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17684&action=view)
patch
Bootstrapped but not yet regtested. Testcase:
/* { dg-do link } */
/* { dg-options "-O2" } */
int main (void)
I have a Athlon64 X2 (Linux 2.6.30-rc3) and I can compile Firefox 3.0.9 fine
with gcc 4.3.3, but if I use gcc 4.4.0 it segfaults. My default optimization is
-O3. If I reduce to -O2, Firefox starts, but with huge letters and windows...
So gcc 4.4.0 is generating bad code trying to compile Firefox 3
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-23 15:31 ---
We need more information than this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from sje at gcc dot gnu dot org 2009-04-23 15:37 ---
Subject: Bug 39623
Author: sje
Date: Thu Apr 23 15:36:48 2009
New Revision: 146650
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146650
Log:
PR testsuite/39623
* gcc.dg/vect/no-vfa-vect-57.c: XF
--- Comment #2 from fragabr at gmail dot com 2009-04-23 15:38 ---
What informa(In reply to comment #1)
> We need more information than this.
What information do you need? Couldn't you compile Firefox yourself to test it?
Or if someone uses x86_64 I'm sure he/she will notice this.
Anywa
--- Comment #2 from sje at cup dot hp dot com 2009-04-23 15:39 ---
Fixed with test suite changes to the failing tests.
--
sje at cup dot hp dot com changed:
What|Removed |Added
---
--- Comment #3 from paolo dot carlini at oracle dot com 2009-04-23 15:43
---
See here:
http://gcc.gnu.org/bugs.html#report
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39869
A common way to do array bounds checking is to cast the index i to unsigned and
then check
if ((unsigned)i > (unsigned)length)
abort();
instead of
if (i >= length || i < 0)
abort();
The phrases are equivalent, but VRP doesn't know that so the bounds check is
not eliminated.
The pro
--- Comment #1 from aph at gcc dot gnu dot org 2009-04-23 15:46 ---
Sorry, typo'd the first expression. Should be
if ((unsigned)i >= (unsigned)length)
abort();
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39870
--- Comment #2 from aph at gcc dot gnu dot org 2009-04-23 15:47 ---
typedef struct
{
int length;
int data[];
} t_m;
t_m *m;
int foo()
{
int val = 0;
int i;
for (i = 0; i < m->length; i++)
{
#ifdef BORKED
if ((unsigned int)i >= (unsigned int)m->length)
#else
i
--- Comment #2 from drangon dot mail at gmail dot com 2009-04-23 15:49
---
(In reply to comment #1)
> Can you try this again, there were some Exceptions handling issues recently.
>
I update the newest gcc code from SVN (20090423), and rebuilt the toolchain.
The application bu
--- Comment #3 from aph at gcc dot gnu dot org 2009-04-23 15:49 ---
-DBORKED on the left
foo: foo:
.LFB0: .LFB0:
.cfi_startproc .cfi_startproc
subq$8, %rsp <
.cfi_def_cfa_offset 1
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-23 15:50 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-23 15:51
---
Interesting. Out of curiosity, why people don't naturally use an unsigned type
for an index?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39870
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org
|dot org |
--- Comment #11 from anmol at freescale dot com 2009-04-23 15:53 ---
Fix (for generic ELF systems) and test program for regression suite posted
here:
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01807.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39383
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-04-23 15:54
---
> The problem is that this is such a common idiom that it will affect many
> programs.
Even worse: the folder synthesizes the problematic form from the original one.
--
ebotcazou at gcc dot gnu dot org change
--- Comment #6 from paolo dot carlini at oracle dot com 2009-04-23 15:56
---
:(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39870
--- Comment #11 from dodji at gcc dot gnu dot org 2009-04-23 15:56 ---
Subject: Bug 38228
Author: dodji
Date: Thu Apr 23 15:55:47 2009
New Revision: 146651
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146651
Log:
2009-04-23 Dodji Seketeli
gcc/cp/ChangeLog:
PR c
--- Comment #12 from dodji at gcc dot gnu dot org 2009-04-23 15:56 ---
Fixed in 4.3, 4.4 and 4.5.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
me (188 user, 0 system)
With gcc-4.2.4
156 ms cpu time (152 user, 4 system)
With gcc-4.3.3:
180 ms cpu time (180 user, 0 system)
With gcc-4.4.0
280 ms cpu time (280 user, 0 system)
With 4.5.0 20090423 (experimental) [trunk revision 146634]
280 ms cpu time (280 user, 0 system)
--- Comment #50 from lucier at math dot purdue dot edu 2009-04-23 16:00
---
Created an attachment (id=17685)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17685&action=view)
direct.s generated by 4.4.0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #51 from lucier at math dot purdue dot edu 2009-04-23 16:03
---
Forgot to mention, the main loop starts at .L2947.
This is on
model name : Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz
Brad
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #3 from drow at gcc dot gnu dot org 2009-04-23 16:07 ---
Subject: Re: GCC does not emit debug info for a called
function
On Tue, Apr 21, 2009 at 06:07:01PM -, pinskia at gcc dot gnu dot org wrote:
> Oh because constant folding of asin, we remove the reference to
--- Comment #7 from bonzini at gnu dot org 2009-04-23 16:09 ---
Eric, fold only does it for a >= C1 && a <= C2, not for variable C1 and C2. in
fact, in this case it would be illegal to do the transformation if the
front-end did not know that m->length is positive.
--
http://gcc.gnu
--- Comment #8 from bonzini at gnu dot org 2009-04-23 16:10 ---
Eric, fold only does it for constant C1 and C2 in "a >= C1 && a <= C2", not for
variable C1 and C2. in fact, in the other case it would be illegal to do the
transformation. the front-end can do it because it knows that m->
--- Comment #8 from aph at gcc dot gnu dot org 2009-04-23 16:15 ---
2 reasons:
1. Habit.
2. The original test case is written in Java: no unsigned types!
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
The following code:
struct A
{
int version;
const char *name;
void* group;
};
struct B
{
const char *name;
int ok;
};
void func(struct A*, int);
void test(struct B *p)
{
struct A a;
a.name = p->name;
func(&a, p->ok);
}
options: --march=armv5te -mthumb -mthumb-interwork -fpic -Os
--- Comment #9 from aph at gcc dot gnu dot org 2009-04-23 16:16 ---
2 reasons:
1. Habit.
2. The original test case is written in Java: no unsigned types!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39870
--- Comment #9 from paolo dot carlini at oracle dot com 2009-04-23 16:17
---
Ah! Now however, I **must** know why Java doesn't have unsigned types!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855
--- Comment #10 from aph at gcc dot gnu dot org 2009-04-23 16:23 ---
Officially, java doesn't have unsigned types for economy: believe it or not,
Java was once intended to be a small language. However, there are not many
unused bytecodes left, and a full set of signed instructions would
--- Comment #11 from paolo dot carlini at oracle dot com 2009-04-23 16:26
---
Interesting, thanks Andrew.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855
--- Comment #4 from jakub at gcc dot gnu dot org 2009-04-23 16:29 ---
Likely related to https://bugzilla.redhat.com/show_bug.cgi?id=487844
which is a nspr bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39869
--- Comment #4 from alexvod at google dot com 2009-04-23 16:39 ---
A more simple example of this issue:
void func(int*);
void test()
{
int a = 0;
while (1) {
func(&a);
if (a > 12) break;
}
}
GCC rev123918:
push{lr}
sub sp, sp, #12
mov
--- Comment #3 from alexvod at google dot com 2009-04-23 16:49 ---
Another example of sub-optimal register allocation on ARM/thumb with IRA (not
sure if this the same bug or a different one).
int func(char*);
void func2(const char*, int);
void test(char **pSignature)
{
int clazz = 0;
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2009-04-23 16:49
---
> Eric, fold only does it for constant C1 and C2 in "a >= C1 && a <= C2", not
> for
> variable C1 and C2.
Yes, but this fools VRP the same way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39870
--- Comment #5 from fragabr at gmail dot com 2009-04-23 16:50 ---
(In reply to comment #4)
> Likely related to https://bugzilla.redhat.com/show_bug.cgi?id=487844
> which is a nspr bug.
>
Ok, thanks. So I'm closing this bug.
--
fragabr at gmail dot com changed:
What|
--- Comment #22 from bkoz at gcc dot gnu dot org 2009-04-23 16:55 ---
>The hppa port sets long-double-fcts = no in glibc
> and this causes all the aliases to be created, otherwise you'd never
> be able to link anything that used `l' ending math functions. Defining
> __NO_LONG_DOUBLE_MATH
--- Comment #1 from lauras at gcc dot gnu dot org 2009-04-23 17:09 ---
It looks like _cpp_lex_direct lexes ahead even if there unused lookahead
tokens, which later causes uninitialized tokens as reported by valgrind. I am
bootstrapping the patch below which seems to fix the issue.
Index
--- Comment #23 from bkoz at gcc dot gnu dot org 2009-04-23 17:16 ---
So:
* Original submitter is incorrect, there has never been a
__signb...@glibcxx_3.4 symbol, and there should not be one now?
Right. This should have manifested as an abi-check FAIL starting in gcc-4.2, as
a new sym
--- Comment #6 from vmakarov at redhat dot com 2009-04-23 17:27 ---
Jakub, thanks for reducing the test. I'll investigate this bug more.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39856
--- Comment #9 from burnus at gcc dot gnu dot org 2009-04-23 17:33 ---
Paul, this PR might interest you - esp. as you have most experience in that
part of the compiler. (If you are/feel swamped, feel free to de-CC yourself.)
--
burnus at gcc dot gnu dot org changed:
What
integer, allocatable :: a(:), b(:)
integer :: i, j
allocate(a(1:5), b(1:5))
b = 7
i = 4
j = 5
a(1:i) = b(1:j)
end
Produces (3/4) instead of (4/5):
At line 7 of file aff.f90
Fortran runtime error: Array bound mismatch, size mismatch for dimension 1 of
array 'a' (3/4)
--
Summary: Boun
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.4.0 4.5.0
Known to work||4.3.3
1. setup /etc/env.d/02locale with value LANG="ru_RU.UTF-8"
2. Run env-update & source /etc/profile
3. Run gcc -c -Q -march=core2 --help=target. First sentence will be
"Следующие
ключи не
зависят от
целевой
архитектуры:"
- "The following options are NOT target specific"
when on english this sounds
--- Comment #1 from joseph at codesourcery dot com 2009-04-23 19:00 ---
Subject: Re: New: Wrong translation of output "gcc
-c -Q -march=core2 --help=target" to Russian
Please report all translation bugs to the relevant language teams (in this
case g...@mx.ru).
--
http://gcc.gnu
--- Comment #24 from joseph at codesourcery dot com 2009-04-23 19:01
---
Subject: Re: [4.4/4.5 regression] symbol __signb...@glibcxx_3.4
in libstdc++ not exported anymore
On Thu, 23 Apr 2009, jakub at gcc dot gnu dot org wrote:
> --- Comment #21 from jakub at gcc dot gnu dot org
The following code:
void func();
void test(char *signature)
{
char ch = signature[0];
if (ch == 15 || ch == 3)
{
if (ch == 15) func();
}
}
is compiled in suboptimal way by gcc 4.4. Check for ch==3 can be completely
eliminated since func is only called if ch==15. gcc 4.3 is able to prope
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-23 19:18 ---
Works on powerpc-darwin, where THRUTH_ORIF_EXPR is not converted into
THRUTH_OR_EXPR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39874
I think this is from after 4.4 branched:
--
template struct InputIterator
{
InputIterator ()
{
TT i;
(void)*i; // require dereference operator
}
};
InputIterator i;
-
> c++ -c deal.II/source/dofs/dof_renumbering.cc
--- Comment #2 from janus at gcc dot gnu dot org 2009-04-23 20:21 ---
> Janus, can you have a look? It looks like another fallout of your patch.
Indeed, it is.
> If it is not fixable quickly, we should consider backing it out
> until we have a working version.
The fix is quite triv
--- Comment #6 from sega01 at go-beyond dot org 2009-04-23 20:59 ---
(In reply to comment #5)
> GCC 4.4.0 compiled glibc 2.10 works just fine for me on x86_64, i586, i686,
> powerpc and powerpc64.
>
> Anyway, if you say GCC 4.3.3 compiled glibc 2.8 works and 4.4.0 compiled
> doesn't, th
Using module procedure names that collide with the GNU intrinsic extensions
is not possible even with -std=f95:
ale...@novo:~/$ gfortran -c -std=f95 p.f90
p.f90:19.19:
print *, avg(erfc)
1
Error: Intrinsic 'erfc' at (1) is not allowed as an actual argument
p.f90:19.19:
/export/home/sutipirn/drive/tmp/gcc-4.5-20090416/host-sparc64-sun-solaris2.10/prev-gcc/xgcc
-B/export/home/sutipirn/drive/tmp/gcc-4.5-20090416/host-sparc64-sun-solaris2.10/prev-gcc/
-B/export/home/sutipirn/gcccore45/sparc64-sun-solaris2.10/bin/ -c -g -O2
-DIN_GCC -W -Wall -Wwrite-strings -Wstric
--- Comment #1 from kargl at gcc dot gnu dot org 2009-04-23 21:19 ---
Upgrade to 4.4.0. The collision problem is fixed when you use -std=f95.
There is however another problem.
REMOVE:kargl[159] gfc4x -c -std=f95 j.f90
f951: internal compiler error: in build_function_decl, at
fortran/t
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-04-23 21:24
---
Fixing.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
--- Comment #1 from dominiq at lps dot ens dot fr 2009-04-23 21:36 ---
Confirmed on 4.3.3, 4.4.0, and trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39872
1 - 100 of 108 matches
Mail list logo
