--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-12 07:41 ---
Oh, this shows up from the following testcase:
gfortran.fortran-torture/execute/intrinsic_set_exponent.f90
gfortran.fortran-torture/execute/transfer1.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30166
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-12 07:40 ---
This testcase is from gfortran.dg/gomp/appendix-a/a.12.1.f90.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30167
Fortran Testcase:
SUBROUTINE A13( X, XOLD, N, TOL )
!$OMP PARALLEL
DO WHILE( TOOBIG > 0 )
!$OMP MASTER
PRINT *, "Iteration ", C, " TOOBIG=", TOOBIG
!$OMP END MASTER
ENDDO
!$OMP END PARALLEL
END SUBROUTINE A12
We get:
D.1056 = *(.omp_data_i
Fortran testcase (at -O1 and above because of the conversion of memcpy to VCE):
ix = transfer(x,ix)
end program
I cannot find a C testcase for this issue.
--
Summary: Gimplifier sometimes does not produce valid gimple for
addressable = VIEW_
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-12 07:20 ---
I have a fix for this issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Fortran testcase:
res = selected_int_kind (int (t))
end program
This is a related issue to PR 30132 which got me started on this whole mess in
the first place.
--
Summary: Gimplifier does not produce valid gimple for
&(int)real_val
Product: gcc
Testcase (only with the C++ front-end because there is no other way to produce
this kind of internal IR, reduced from g++.dg/init/vector1.C):
typedef signed char v8qi __attribute__ ((vector_size (8)));
int num (void);
v8qi b = (v8qi){ num (), num (), num (), num (), 6, 6, 6, 6 };
--
S
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|/usr/ccs/bin/ld: Duplicate |[4.3 Regression]
|symbol "global destructors |/usr
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-12 06:33 ---
This seems related to PR 7932.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Other
--- Comment #6 from dann at godzilla dot ics dot uci dot edu 2006-12-12
06:07 ---
(In reply to comment #5)
> (In reply to comment #1)
> > Confirmed (but it's not PRE).
> >
> The second is smaller, and no more or less efficient since the addition is
> calculated on both paths anyway.
>
--- Comment #4 from dann at ics dot uci dot edu 2006-12-12 06:01 ---
Subject: Re: [tree-ssa] make "fold" use alias information to optimize pointer
comparisons
"steven at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
> --- Comment #3 from steven at gcc dot gnu dot org 2006-12
I build a new target for experiment, and my GCC version is 4.1.1
I have one question
at combine pass , if
(set ( reg 1)
(and (reg 2)
(const_int 0x8001)))
(cmp (reg1 )(const_0)
if compare code is GE or LT
and src2 is zero
the const_int will be 0x8000
bec
--- Comment #8 from bangerth at dealii dot org 2006-12-12 05:09 ---
Confirmed. The code is valid. The code would have undefined runtime
behavior if the default argument is a) actually used in a call to
commonEventProcessing, and b) is used without any further cast. Neither
is the case he
--- Comment #4 from rmathew at gcc dot gnu dot org 2006-12-12 04:52 ---
Thanks for looking into this Ben. Unfortunately, I no longer build GCC for
MinGW (or for Linux, for that matter) regularly so I'm unable to test your
patch. :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=282
Reduced test case frim Bud Davis
$ cat a.f
integer status
integer i
open(unit=20,file='np',action='write',
& form='unformatted',iostat=status);
print*,'status from open is ',status
do i = 1,5
write(20)i
end do
end
$ cat b.f
integ
--- Comment #46 from hjl at gcc dot gnu dot org 2006-12-12 03:59 ---
Subject: Bug 20218
Author: hjl
Date: Tue Dec 12 03:58:52 2006
New Revision: 119764
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119764
Log:
2006-12-11 H.J. Lu <[EMAIL PROTECTED]>
PR middle-end/1798
--- Comment #29 from hjl at gcc dot gnu dot org 2006-12-12 03:59 ---
Subject: Bug 17982
Author: hjl
Date: Tue Dec 12 03:58:52 2006
New Revision: 119764
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119764
Log:
2006-12-11 H.J. Lu <[EMAIL PROTECTED]>
PR middle-end/1798
GCC doesn't currently generate DW_TAG_template_*_param, and it should to
improve C++ debuggability (and allow us to shorten the DW_AT_names of template
instantiations).
--
Summary: GCC should generate dwarf info about template parameters
Product: gcc
Version: 4.3
--- Comment #45 from mmitchel at gcc dot gnu dot org 2006-12-12 02:14
---
This version is OK for mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-12-12 01:53
---
Fixed in 4.1.2, 4.2.0.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
A
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-12-12 01:47
---
Subject: Bug 29732
Author: mmitchel
Date: Tue Dec 12 01:46:57 2006
New Revision: 119759
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119759
Log:
PR c++/29732
* cp-tree.h (DECL_USE_TEMPLAT
--- Comment #3 from richard at beatnik dot com 2006-12-12 01:29 ---
Ahh,
I see.
Because the a is supposed to be long long, that means that it is of size 8,
which would mean that it takes two regs (or stack spaces, or where ever gcc
stores it's arguments). Then the second %d in the str
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-12 01:24 ---
The problem is EXECUTE_IF_SET_IN_BITMAP does not like the bitmap to change from
underneath it.
I have a patch which fixes this issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-12 01:22 ---
*** Bug 30126 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-12-12 01:22
---
Mark this as a dup of bug 28624.
*** This bug has been marked as a duplicate of 28624 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-12-12 01:22
---
Reopening for a second to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-12 01:01 ---
4.0 and above give a better warning message for this issue:
t1.c:12: warning: format '%d' expects type 'int', but argument 2 has type 'long
long int'
This is not a bug in GCC but rather your code in that the enum y
--- Comment #1 from richard at beatnik dot com 2006-12-12 00:51 ---
Created an attachment (id=12787)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12787&action=view)
test file for creating bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30160
Hello,
I'm compiling on cygwin on my Dell Laptop. I'm running windows xp pro, with
the 3.4.4 version of gcc
my source file:
#include
typedef enum {
ac = -1,
ab = 0x,
aa = 1,
} en;
int main()
{
en a = ab;
printf("a = %d sizeof %d\n", a, sizeof(e
On sh-elf, the function foo in 20010422-1.c
unsigned int foo(unsigned int x)
{
if (x < 5)
x = 4;
else
x = 8;
return x;
}
is compiled to
foo:
mov.l r14,@-r15
mov r15,r14
mov #4,r1
cmp/hi r1,r1
bf/s.L6
mov #4,r0
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-11 23:20 ---
Instead of mode checking, what about checking the code of the type inaddition,
though maybe checking the for INTEGERAL_TYPE_P before the check for the mode
will also fix this issue?
--
http://gcc.gnu.org/bugzill
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-12-11 23:17
---
I did post a patch to fix this following your comments on the patch for PR27961
here - http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00867.html. It seems like
this one slipped through the cracks.
I'll give it anot
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-12-11 23:17 ---
This is caused by
2006-05-09 Dirk Mueller <[EMAIL PROTECTED]>
Richard Guenther <[EMAIL PROTECTED]>
PR middle-end/27498
* fold-const.c (fold_read_from_constant_string): Relax check
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-12-11 23:15
---
As far as I can see, we are miscompiling the compiler as the stage1's cc1 works
for this testcase but stage3's cc1 does not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30126
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-12-11 22:17 ---
Subject: Bug 28125
Author: bkoz
Date: Mon Dec 11 22:17:09 2006
New Revision: 119749
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119749
Log:
2006-12-11 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libstd
--- Comment #12 from bkoz at gcc dot gnu dot org 2006-12-11 22:16 ---
> But I think it just makes the bug latent again.
maybe. But I can compile again so I will close this.
-benjamin
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-12-11 21:55 ---
Created an attachment (id=12786)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12786&action=view)
Patch++
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-12-11 21:29 ---
Subject: Bug 30113
Author: rakdver
Date: Mon Dec 11 21:29:44 2006
New Revision: 119748
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119748
Log:
PR rtl-optimization/30113
* loop-iv.c (implie
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30158
The following invalid code snippet triggers an ICE since GCC 4.0.0
(and in GCC 3.4.0 - 3.4.3):
===
void foo(int i)
{
(i ? 1 : 2) = ({ X; });
}
===
bug.cc: In function 'void foo(int)':
bug.cc:3: error: 'X' was not declared in this scope
bug
The following tests fail on hppa1.1-hp-hpux10.20:
FAIL: g++.old-deja/g++.other/init18.C execution test
FAIL: g++.old-deja/g++.other/init19.C execution test
FAIL: g++.old-deja/g++.other/init5.C execution test
These tests are xfailed on targets that don't support cxa_atexit
using using the check_cx
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-12-11 21:12
---
Sorry, forgot to add the error message:
bug.cc:3: error: 'X' was not declared in this scope
bug.cc:3: internal compiler error: tree check: expected var_decl, have
field_decl in cp_finish_decl, at cp/decl.c:5092
Pl
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30156
The following invalid testcase causes an ICE on the 4.1 branch, 4.2 branch
and mainline (4.1.0 and 4.1.1 are not affected, though):
struct A
{
template int foo(X);
};
The underlying problem is the same as in PR27961, bu
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-12-11 21:06
---
(In reply to comment #10)
> Diego I HEART YOU
>
> r119746
But I think it just makes the bug latent again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30126
--- Comment #10 from bkoz at gcc dot gnu dot org 2006-12-11 21:02 ---
Diego I HEART YOU
r119746
fixes it.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30126
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-12-11 21:00
---
> Fixed on mainline.
Alas this is only partially true:
Although the original testcase is indeed fixed on mainline (and 4.2 branch),
the following variant (which only differs in the return type of the template
func
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-12-11 20:58
---
Fixed on 4.2 also.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2006-12-11 20:58
---
Commited to 4.2, both my patch and Tobias' fix. Thanks Tobias for fixing it!
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-12-11 20:57
---
Subject: Bug 29973
Author: fxcoudert
Date: Mon Dec 11 20:57:10 2006
New Revision: 119747
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119747
Log:
PR fortran/29892
* trans-intrinsic.c (gf
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-12-11 20:57
---
Subject: Bug 29892
Author: fxcoudert
Date: Mon Dec 11 20:57:10 2006
New Revision: 119747
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119747
Log:
PR fortran/29892
* trans-intrinsic.c (gf
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2006-12-11 20:57
---
Subject: Bug 29711
Author: fxcoudert
Date: Mon Dec 11 20:57:10 2006
New Revision: 119747
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119747
Log:
PR fortran/29892
* trans-intrinsic.c (g
--- Comment #8 from manu at gcc dot gnu dot org 2006-12-11 20:52 ---
(In reply to comment #5)
> int x;
>
> enum e { E = 0 * x };
>
>
> which currently compiles without even a warning using -pedantic-errors.
> This is exactly the sort of thing that Joseph's struct c_expr were intended
--- Comment #1 from danglin at gcc dot gnu dot org 2006-12-11 20:32 ---
It seems that the special handling for 'F' was removed...
2006-10-31 Geoffrey Keating <[EMAIL PROTECTED]>
...
* tree.c (get_file_function_name): Rename from
get_file_function_name_long; im
--- Comment #9 from rask at sygehus dot dk 2006-12-11 20:24 ---
Created an attachment (id=12785)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12785&action=view)
Partial patch
Please try this patch. It removes the ICE, but the code may not run on 68000
and 68010 CPUs because there
--- Comment #11 from reichelt at gcc dot gnu dot org 2006-12-11 20:23
---
Btw, the following C++ example fails to link even without -O:
=
const char s[] = "";
const char *const p = s;
int main()
{
return 0;
}
=
--
reichelt
--- Comment #2 from manu at gcc dot gnu dot org 2006-12-11 19:35 ---
(In reply to comment #1)
> I think the C front-end is incorrect in not warning, though someone has to
> look
> into the standard to be sure.
>
Is there a searchable version of the standard?
Anyway, the following cod
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-11 19:29 ---
Just fixed by:
http://gcc.gnu.org/ml/gcc-cvs/2006-12/msg00364.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from herring at lanl dot gov 2006-12-11 19:24 ---
(In reply to comment #1)
> *** This bug has been marked as a duplicate of 27558 ***
Thanks for finding that for me! I tried for an hour to locate this bug in the
database (because I discovered it some time ago; presumably
> cat gcc.c
static inline void foo (void) { }
void baz (void (*f) (void));
void bar (void) { baz (foo); }
> gcc -O0 -c -fPIC gcc.c
> gcc -shared -o gcc.so gcc.o
/usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../x86_64-suse-linux/bin/ld:
gcc.o: relocation R_X86_64_PC32 against `foo' can not be use
--- Comment #7 from s__nakayama at infoseek dot jp 2006-12-11 19:21 ---
Is this still active?
gcc 4.1.1 accept Andrew's testcase in comment #1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20724
bootstrap of trunk broken on Solaris x86 as of 12/8/06, I believe. It looks
like varasm.c is giving warnings:
/u01/var/tmp/gcc_trunk_svn/gcc_20061211/./prev-gcc/xgcc
-B/u01/var/tmp/gcc_trunk_svn/gcc_20061211/./prev-gcc/
-B/opt/gcc-4.3/i386-pc-solaris2.10/bin/ -c -g -O2 -DIN_GCC -W -Wall
-Wwri
Executing on host: /xxx/gnu/gcc/objdir/./gcc/g++ -shared-libgcc
-B/xxx/gnu/gcc/o
bjdir/./gcc -nostdinc++
-L/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/
src -L/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/src/.libs
-B/opt/gnu
/gcc/gcc-4.3.0/hppa1.1-hp-hpux10.20/bin/
-B/opt/gnu/gcc/
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30149
--- Comment #1 from danglin at gcc dot gnu dot org 2006-12-11 18:17 ---
Created an attachment (id=12784)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12784&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30149
--- Comment #42 from dberlin at gcc dot gnu dot org 2006-12-11 18:13
---
This bug (against the regular development branches) should not be marked fixed
simply because a patch was applied to the redhat branch.
Either it needs to go into mainline 4.1, or the bug needs to be closed in som
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-12-11 18:00 ---
still reducing it, I have it down to 8521 lines.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30126
/home/dave/gcc-4.3/objdir/./prev-gcc/xgcc
-B/home/dave/gcc-4.3/objdir/./prev-gcc
/ -B/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/bin/ -c -g -O2 -DIN_GCC -W
-
Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-lon
g-long -Wno-variadic-macros -Wno-overlength-strings -Wol
--- Comment #44 from hjl at lucon dot org 2006-12-11 17:04 ---
This patch
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00594.html
doesn't cause any regressions on AIX nor HPUX:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00595.html
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00754.h
--- Comment #4 from bkoz at gcc dot gnu dot org 2006-12-11 16:55 ---
Created an attachment (id=12783)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12783&action=view)
Patch to remove AC_CHECK_LIB.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28125
The following code tests that values are passed correctly from a
call to a function. This fails, when the followign code is
compiled with -O2 and executed:
foo: foo.c:65: callee_b0f: Assertion `b14.b3 == b20.b3' failed.
The code below is automatically generated explicitly to test for
par
--- Comment #3 from bkoz at gcc dot gnu dot org 2006-12-11 16:53 ---
Created an attachment (id=12782)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12782&action=view)
Patch to remove AC_CHECK_LIB.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28265
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[regression 4.3] ICE in |[4.3 Regression] ICE in
|fold_convert with -O2
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-12-11 16:25 ---
This fixes it:
Index: fold-const.c
===
*** fold-const.c(revision 119733)
--- fold-const.c(working copy)
*** fold_unary_to_c
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-11 16:19 ---
#2 0x007395cf in fold_read_from_constant_string (exp=0x2ab7c225bd00)
at /space/rguenther/src/svn/trunk/gcc/fold-const.c:12854
12854 return fold_convert (TREE_TYPE (exp),
(gdb) call debug_generi
--- Comment #35 from jv244 at cam dot ac dot uk 2006-12-11 16:08 ---
(In reply to comment #34)
> CP2k actually gives here an ICE with -O2 (PR 30147)
> at least when I use ./do_regtest (otherwise I didn't saw it). I did not yet
> look at why the calculation results are wrong.
>
yes, I'm
--- Comment #34 from burnus at gcc dot gnu dot org 2006-12-11 15:56 ---
CP2k actually gives here an ICE with -O2 (PR 30147)
at least when I use ./do_regtest (otherwise I didn't saw it). I did not yet
look at why the calculation results are wrong.
--
http://gcc.gnu.org/bugzilla/show_
Today's gfortran crashes with "-c -O2" for the program below.
It works with today's 4.2.0 and with "-O".
I don't see right away whether this is a middle end or middle-end triggered
front-end problem.
input_cp2k_motion2.f90: In function 'create_neb_section':
input_cp2k_motion2.f90:12: internal com
--- Comment #3 from georgeh at rentec dot com 2006-12-11 14:34 ---
(In reply to comment #2)
>
> Is this what you wished?
>
Yes.
--
georgeh at rentec dot com changed:
What|Removed |Added
--- Comment #4 from uros at gcc dot gnu dot org 2006-12-11 14:06 ---
Subject: Bug 30120
Author: uros
Date: Mon Dec 11 14:06:07 2006
New Revision: 119734
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119734
Log:
PR target/30120
Revert:
2006-11-15 Uros Bi
I think the following program is wrong as one uses a passes a do variable to an
intent(inout) (or intent(out) subroutine).
However, neither g95, sunf95 nor NAG f95 complain at compile time. Using nagf95
-C=all I get at run time:
Actual argument for INTENT(INOUT) dummy argument I is an expression
(
--- Comment #2 from bkoz at gcc dot gnu dot org 2006-12-11 13:56 ---
Hey Ranjit. It looks like this error is from extc++.h.gch, the precompiled
header for libstdc++ that includes std/tr1/ext.
>From the file libstdc++-v3/include/ext/codecvt_specializations.h:
#ifndef _EXT_CODECVT_SPEC
--- Comment #1 from bkoz at gcc dot gnu dot org 2006-12-11 13:49 ---
Mine.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at g
sion 4.3.0 20061211 (experimental).
--
pmason at ricardo dot com changed:
What|Removed |Added
Summary|Print/write |Fortran 90: write
--- Comment #34 from irar at il dot ibm dot com 2006-12-11 13:02 ---
Created an attachment (id=12781)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12781&action=view)
"Good" rs6000.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
--- Comment #1 from pmason at ricardo dot com 2006-12-11 12:58 ---
Created an attachment (id=12780)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12780&action=view)
Fortran 90 testcase for zero-sized array printing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30145
--- Comment #33 from irar at il dot ibm dot com 2006-12-11 12:57 ---
Created an attachment (id=12779)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12779&action=view)
"Bad" rs6000.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
GCC build triplet: gcc version 4.3.0 20061211 (experimental)
GCC host triplet: suse9 (x86_64)
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30145
--- Comment #32 from irar at il dot ibm dot com 2006-12-11 12:46 ---
I am attaching the "bad" rs6000.s (generated with vectorization) and "good"
rs6000.s (generated with vectorization and -fno-move-loop-invariants) using
revision 110852 (from February 2006). I looked over these a bit, bu
--- Comment #33 from jv244 at cam dot ac dot uk 2006-12-11 11:54 ---
Running the CP2K regtests now results in:
number of FAILED tests 24
(these are just the runs that do not complete, I have not checked that the runs
that finish also generate the right numbers. This can be reproduced us
--- Comment #32 from jv244 at cam dot ac dot uk 2006-12-11 11:29 ---
(In reply to comment #31)
> > > gcc version 4.3.0 20061210 (experimental)
> > simple testcase for the segfault:
> I tried it with gfortran 4.3 and 4.2 (today's build) and an older 4.1 build
> and
> neither crashes. val
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30126
no error.
The original program gives here:
** ** PROGRAM ENDED AT 20061211
110945.641
i.e. it also seems to work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #30 from jv244 at cam dot ac dot uk 2006-12-11 09:51 ---
(In reply to comment #29)
simple testcase for the segfault:
SUBROUTINE S(unit_number)
character(len=100) :: status_string
integer :: unit_number,istat
status_string="KEEP"
CLOSE (UNIT=unit_number,IOSTAT=istat,STATUS=T
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-11 08:20 ---
I think the C front-end is incorrect in not warning, though someone has to look
into the standard to be sure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30139
On Mon, 2006-12-11 at 11:06 +0300, XXX XXX wrote:
> Dear Sirs,
>
> I use gcc 3.4.5 and received following incorrect result in the program.
> On the gcc site exist report about incorrect behavior of ++ operator but not
> this situation. I hope that it will be usefull.
>
> I have developed some st
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-11 08:09 ---
*** Bug 30144 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-11 08:09 ---
*** This bug has been marked as a duplicate of 15272 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
1 - 100 of 102 matches
Mail list logo
