--- Comment #10 from jakub at gcc dot gnu dot org 2009-04-24 06:58 ---
Subject: Bug 39794
Author: jakub
Date: Fri Apr 24 06:58:02 2009
New Revision: 146669
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146669
Log:
PR rtl-optimization/39794
* alias.c (canon_true_
--- Comment #1 from david dot sagan at gmail dot com 2009-04-24 06:36
---
Created an attachment (id=17686)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17686&action=view)
Example program which shows the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39879
The program (see attachment) was run on Linux. Platform details:
uname -a:
Linux lnx180c.lns.cornell.edu 2.6.9-67.0.1.ELsmp #1 SMP Wed Dec 19 15:44:14
CST 2007 i686 i686 i386 GNU/Linux
cat /etc/redhat-release:
Scientific Linux SL release 4.5 (Beryllium)
Compiler:
GNU Fortran (GCC) 4.
--- Comment #8 from lauras at gcc dot gnu dot org 2009-04-24 05:50 ---
*** Bug 34865 has been marked as a duplicate of this bug. ***
--
lauras at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from lauras at gcc dot gnu dot org 2009-04-24 05:50 ---
It was later reported as PR/38781 and fixed.
No valgrind errors here with r146637.
*** This bug has been marked as a duplicate of 38781 ***
--
lauras at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from kargl at gcc dot gnu dot org 2009-04-24 05:22 ---
This patch allows the code in comment #2 to compile with -std=f95.
Don't know if it is correct.
REMOVE:kargl[194] svn diff trans-decl.c
Index: trans-decl.c
--- Comment #8 from fago at earthlink dot net 2009-04-24 03:29 ---
I'm also seeing this on a fresh bootstrap of 4.4.0.
I also have gfortran 4.2 installed, and seem to recall the problem surfacing
here, so perhaps it is not related to 4.3 or 4.4, but something left over from
4.2:
gfortr
/* DFP TR 24732 == WG14 / N1312 */
#define __STDC_WANT_DEC_FP__ /* Tell implementation that we want Decimal FP */
#include
int main(void){
/*
* If DEC_EVAL_METHOD is 0, then these triples are not the same.
* If DEC_EVAL_METHOD is 1 or 2, then these suffer double rounding
* and are the
--- 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
--- 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 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
/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
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:
--- 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
--- 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
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 #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
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 #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
--- 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
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
--
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
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
--- 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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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
--
bonzini at gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org
|dot org |
--- 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
--- 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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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
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 #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)
--
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 #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
--- 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 #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 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 #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 #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 #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 #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 #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 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
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
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
--- 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
--- 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 #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
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 #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:
--- 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),
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 #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
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
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_
--- 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
--- 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 #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 #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 #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 #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
--- 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 #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 #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
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywo
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- 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
-
1 - 100 of 108 matches
Mail list logo
