--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-17 07:57 ---
Subject: Bug 36089
Author: jakub
Date: Mon Nov 17 07:55:52 2008
New Revision: 141941
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141941
Log:
PR c++/36089
* init.c (constant_value_1): Handle
--- Comment #10 from spark at gcc dot gnu dot org 2008-11-17 06:13 ---
I agree that the overeager has the worse worst-case bound. I'll happily approve
a patch that drops overeager and leave double-queuing only, provided we have
empirical data over some known programs to show that it is a
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-11-17 05:03
---
The shifting of the decimal point between 1000. and 1001. is an artefact of how
we compute the format specifiers in the OUTPUT_FLOAT macro in write_float.def.
I am working on a solution to that part of this.
The
--- Comment #22 from rakdver at gcc dot gnu dot org 2008-11-17 03:44
---
(In reply to comment #20)
> To add to comment #18, after r128272 GCC for powerpc-linux no longer generates
> bdnz for:
> ...
A patch for this testcase:
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00792.html
--
--- Comment #1 from aleksi dot nurmi at helsinki dot fi 2008-11-17 02:01
---
Created an attachment (id=16707)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16707&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38167
It appears that the following inline accessor function to stdin doesn't do it's
job if -O2 optimization is turned on, thus letting a null pointer pass and
causing a segfault. This doesn't happen if the function is not declared inline.
Version: gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3)
Command line:
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-11-17
01:02 ---
Created an attachment (id=16706)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16706&action=view)
assembly file for g++.dg/ext/visibility/class1.C at -m64 on i686-apple-darwin9
with -fomit-frame-point
The g++.dg/ext/visibility/class1.C test case fails at -m64 on
i686-apple-darwin9 as follows...
Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/gcc/testsuite/g++/../../g++
-B/sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/gcc/testsuite/g++/../../
/sw/src
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2008-11-17
00:53 ---
typo in original attachment description. It wasn't generated with
-fomit-frame-pointer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38165
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-11-17
00:51 ---
Created an attachment (id=16705)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16705&action=view)
assembly file for g++.dg/pubtypes.C at -m32 on i686-apple-darwin9 with
-fomit-frame-pointer
--
ht
The g++.dg/pubtypes.C test case fails at both -m32 and -m64 on
i686-apple-darwin9. The appears as...
Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/gcc/testsuite/g++/../../g++
-B/sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/gcc/testsuite/g++/../../
/sw/src
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2008-11-17
00:37 ---
Created an attachment (id=16704)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16704&action=view)
assembly file for gcc.target/i386/pr34256.c at -m64 on i686-apple-darwin9 with
-fomit-frame-pointer
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2008-11-17
00:34 ---
The gcc.target/i386/pr34256.c test case is still failing as...
Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-11-17
00:30 ---
Created an attachment (id=16703)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16703&action=view)
assembly file for gcc.target/i386/amd64-abi-3.c at -m64 on i686-apple-darwin9
--
http://gcc.gnu.o
The gcc.target/i386/amd64-abi-3.c test case fails at -m64 on i686-apple-darwin9
as follows...
Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/gcc/
/sw/src/fink.build/gcc44-4.3.999-20081116/gcc-4.4
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2008-11-17
00:25 ---
Created an attachment (id=16702)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16702&action=view)
123t.optimized file for gcc.dg/tree-ssa/loop-3.c at -m64 on i686-apple-darwin9
--
http://gcc.gnu.
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-11-17
00:25 ---
Created an attachment (id=16701)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16701&action=view)
assembly file for gcc.dg/tree-ssa/loop-3.c at -m64 on i686-apple-darwin9
--
http://gcc.gnu.org/bu
The gcc.dg/tree-ssa/loop-3.c test case fails at -m64 on i686-apple-darwin9 with
the failure...
Executing on host:
/sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc44-4.3.999-20081116/darwin_objdir/gcc/
/sw/src/fink.build/gcc44-4.3.999-20081116/gcc-4.4
--- Comment #2 from eric dot weddington at atmel dot com 2008-11-17 00:15
---
(In reply to comment #1)
> What's sizeof (void *) and sizeof (long) for avr?
>
char: 8-bit
int/short: 16-bit
pointer: 16-bit
long: 32-bit
long long: 64-bit
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #3 from burnus at gcc dot gnu dot org 2008-11-17 00:01 ---
(In reply to comment #2)
> > By the way, the following also fails:
> The error is fixed by the following trivial patch:
Janus, do you plan to submit it?
* * *
Regarding the ICE, the following patch seems to work;
--- Comment #19 from mikael at gcc dot gnu dot org 2008-11-16 22:46 ---
Subject: Bug 35681
Author: mikael
Date: Sun Nov 16 22:45:10 2008
New Revision: 141931
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141931
Log:
2008-11-16 Mikael Morin <[EMAIL PROTECTED]>
PR fortr
On Linux/Intel64, revision 141928 gave
make[8]: Entering directory
`/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/boehm-gc'
Switched to incremental mode
Emulating dirty bits with mprotect/signals
Lost a node at level 7 - collector is broken
Test failed
/bin/sh: line 4: 26509 Aborted
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-16 22:26 ---
What's sizeof (void *) and sizeof (long) for avr?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #12 from pault at gcc dot gnu dot org 2008-11-16 22:25 ---
Thomas,
Since you are there, bar the shouting, I thought that I would assign you:-)
Cheers and thanks
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
#ifndef FOO
#define FOO sizeof(void *)
#elif FOO
#endif
t.c:3:7: error: missing binary operator before token "("
I expect it's caused by the fix to bug #36320.
--
Summary: #elif breaks
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severi
--- Comment #11 from ubizjak at gmail dot com 2008-11-16 21:09 ---
Also fails in return from function:
--cut here--
struct S2848
{
unsigned int a;
_Complex int b;
};
struct S2848 s2848;
struct S2848 __attribute__((noinline))
check2848 (struct S2848 arg0)
{
s2848.a = 4027477739U;
--- Comment #10 from rsandifo at gcc dot gnu dot org 2008-11-16 21:08
---
Fixed on mainline.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from mikael at gcc dot gnu dot org 2008-11-16 21:05 ---
Fixed on trunk, closing
(In reply to comment #9)
> Note also that there are other similar instances for which gfortran gives an
> ICE after error messages and that are not fixed by the patch, see:
Those are ice-on
--- Comment #10 from ubizjak at gmail dot com 2008-11-16 20:58 ---
Real bug with argument passing. Confirmed on x86_64-linux-gnu with the
testcase:
--cut here--
struct S2848
{
unsigned int a;
_Complex int b;
};
struct S2848 s2848;
void __attribute__((noinline))
check2848 (struct S
--- Comment #10 from mikael at gcc dot gnu dot org 2008-11-16 20:45 ---
Subject: Bug 37992
Author: mikael
Date: Sun Nov 16 20:44:33 2008
New Revision: 141927
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141927
Log:
2008-11-16 Mikael Morin <[EMAIL PROTECTED]>
PR fort
--- Comment #11 from tkoenig at gcc dot gnu dot org 2008-11-16 20:38
---
Regression-test and full patch, including test cases, tomorrow.
RL keeps interfering :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
--- Comment #9 from rsandifo at gcc dot gnu dot org 2008-11-16 20:32
---
Subject: Bug 38052
Author: rsandifo
Date: Sun Nov 16 20:31:13 2008
New Revision: 141926
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141926
Log:
gcc/
PR target/38052
* config/mips/mips.c
--- Comment #9 from ubizjak at gmail dot com 2008-11-16 20:28 ---
(In reply to comment #8)
> This failing testcase produces the following in gdb...
> #0 0x7fff83829ee6 in __kill ()
> #1 0x7fff8389af4d in abort ()
> #2 0x00010f6f in main ()
> (gdb)
>
> Is there anyth
--- Comment #8 from rsandifo at gcc dot gnu dot org 2008-11-16 20:27
---
Subject: Bug 38052
Author: rsandifo
Date: Sun Nov 16 20:25:40 2008
New Revision: 141925
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141925
Log:
gcc/
PR target/38052
* config/mips/mips.c
--- Comment #3 from hjl at gcc dot gnu dot org 2008-11-16 19:49 ---
Subject: Bug 37790
Author: hjl
Date: Sun Nov 16 19:47:40 2008
New Revision: 141924
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141924
Log:
2008-11-16 Vladimir Makarov <[EMAIL PROTECTED]>
PR bootstr
--- Comment #10 from mikael at gcc dot gnu dot org 2008-11-16 19:44 ---
(In reply to comment #9)
Those are only details, it works nicely :-).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
--- Comment #8 from hjl dot tools at gmail dot com 2008-11-16 19:21 ---
(In reply to comment #7)
> I am not convinced that PR 38128 is a duplicate of this bug. The test
> doesn't fail if I disable the use of CFI directives on hppa-unknown-linux-gnu.
> In debugging, there also seems to b
--- Comment #7 from danglin at gcc dot gnu dot org 2008-11-16 19:17 ---
I am not convinced that PR 38128 is a duplicate of this bug. The test
doesn't fail if I disable the use of CFI directives on hppa-unknown-linux-gnu.
In debugging, there also seems to be an exception in the eh code c
--- Comment #1 from kargl at gcc dot gnu dot org 2008-11-16 19:08 ---
Here's the testcase from Tobias on IRC
use iso_c_binding
complex(c_double), target :: z
type(c_ptr) :: ptr
ptr = c_loc(z)
end
Note, the standard says that c_double and c_double_complex are the
same value, s
--- Comment #2 from janus at gcc dot gnu dot org 2008-11-16 18:59 ---
(In reply to comment #1)
> By the way, the following also fails:
>
> module m
> procedure(), pointer :: procptr
> end module m
>
> use m
> external foo
> procptr => foo
> end
>
> with Error: 'procptr' in the pointer
--- Comment #9 from mikael at gcc dot gnu dot org 2008-11-16 18:46 ---
(In reply to comment #8)
Are you sure this is needed ?
if (sempty)
{
- /* Switch immediately to the pad array. */
+ /* Pretend we are using the pad array the first time around, too. */
src
Found in the README to
http://www.lrz-muenchen.de/services/software/mathematik/gsl/fortran/
gfortran is quite picky with regards to the C binding type, i.e. it does not
like
use iso_c_binding
complex(c_double),target :: z ! correct would be: c_double_complex
however it is not failing rig
ICE on AVR target: gcc.c-torture/execute/pr38051.c compilation, -O3
-fomit-frame-pointer -funroll-all-loops -finline-functions
Executing on host: /usr/local/avrdev/gcc/build/gcc/xgcc
-B/usr/local/avrdev/gcc/build/gcc/
/usr/local/avrdev/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr38051.c -w
-O
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-11-16 16:22
---
Fixed on trunk
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-11-16 16:20
---
Subject: Bug 38097
Author: jvdelisle
Date: Sun Nov 16 16:18:36 2008
New Revision: 141920
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141920
Log:
2008-11-16 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #2 from vmakarov at redhat dot com 2008-11-16 16:14 ---
I waited more than hour to compile it on 1.2Ghz itanium and canceled the
compilation. The problem is in coalescing stack slots. The code was already
rewritten for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-11-16 16:13
---
Subject: Bug 38097
Author: jvdelisle
Date: Sun Nov 16 16:12:16 2008
New Revision: 141919
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141919
Log:
2008-11-16 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-11-16 16:03 ---
Created an attachment (id=16700)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16700&action=view)
Patch for the library part
Well, here's a patch for the library part. Apparently, nobody ever paid much
attent
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2008-11-16
15:55 ---
This failing testcase produces the following in gdb...
gdb ./tmpdir-gcc-dg-struct-layout-1-t028-01.exe
GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40 UTC 2008)
Copyright 2004 Free So
--- Comment #7 from mikael at gcc dot gnu dot org 2008-11-16 15:22 ---
(In reply to comment #6)
> I'm onto it; the problems are in reshape.m4 / reshape_generic.c .
>
Ok, leaving it to you.
According to my tests, sstride0 has suspicious values.
--
http://gcc.gnu.org/bugzilla/show
--- Comment #3 from danglin at gcc dot gnu dot org 2008-11-16 15:12 ---
No. It fails at all optimizations. sizeof (long) is the same as sizeof (void
*)
on the PA.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38158
--- Comment #2 from danglin at gcc dot gnu dot org 2008-11-16 15:10 ---
Starting program: /home/dave/gcc-4.4/objdir/gcc/testsuite/gcc/pr38051.x0g
Breakpoint 1, main ()
at /home/dave/gcc-4.4/gcc/gcc/testsuite/gcc.c-torture/execute/pr38051.c:202
202 __builtin_abort ();
(gdb)
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-16 15:09 ---
Only at -O0? If not probably because the testcase assumes sizeof (long) ==
sizeof (void *).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
At all optimization levels, this new test fails:
Executing on host: /home/dave/gcc-4.4/objdir/gcc/xgcc
-B/home/dave/gcc-4.4/objdi
r/gcc/ /home/dave/gcc-4.4/gcc/gcc/testsuite/gcc.c-torture/execute/pr38051.c -w
-O0 -lm -o /home/dave/gcc-4.4/objdir/gcc/testsuite/gcc/pr38051.x0
(timeo
ut = 3
--- Comment #17 from burnus at gcc dot gnu dot org 2008-11-16 14:21 ---
FIXED on the trunk (4.4.0). Thanks for the report!
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #16 from burnus at gcc dot gnu dot org 2008-11-16 14:21 ---
Subject: Bug 38095
Author: burnus
Date: Sun Nov 16 14:19:38 2008
New Revision: 141917
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141917
Log:
2008-11-16 Tobias Burnus <[EMAIL PROTECTED]>
PR for
/edwin/gcc_inst/ --enable-languages=c,c++
--enable-checking=assert,df,fold,gc,misc,rtl,rtlflag,runtime,tree
Thread model: posix
gcc version 4.4.0 20081116 (experimental) [trunk revision 141912] (GCC)
--
Summary: -fconserve-stack enabled by default
Product: gcc
--- Comment #1 from ubizjak at gmail dot com 2008-11-16 14:16 ---
Can you send us a patch?
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNC
--- Comment #8 from dominique dot pelle at gmail dot com 2008-11-16 14:06
---
I should add that building with -O3 -D_FORTIFY_SOURCE=1 also
works which is better.
Reading about _FORTIFY_SOURCE in the following link, everything
makes sense now.
Snippet from http://mail-index.netbsd.org/
--- Comment #6 from tkoenig at gcc dot gnu dot org 2008-11-16 13:58 ---
(In reply to comment #5)
>
> for (2), I'm puzzled. :(
I'm onto it; the problems are in reshape.m4 / reshape_generic.c .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
--- Comment #7 from dominique dot pelle at gmail dot com 2008-11-16 13:48
---
reading through the man page of gcc, I stumbled upon this in
the section about -O2:
==
NOTE: In Ubuntu 8.10 and later versions, -D_FORTIFY_SOURCE=2
is set by
--- Comment #5 from mikael at gcc dot gnu dot org 2008-11-16 13:45 ---
Index: simplify.c
===
--- simplify.c (révision 141833)
+++ simplify.c (copie de travail)
@@ -3410,9 +3410,6 @@ is_constant_array_expr (gfc_expr *e)
--- Comment #2 from jakub at gcc dot gnu dot org 2008-11-16 13:02 ---
*** This bug has been marked as a duplicate of 37739 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from jakub at gcc dot gnu dot org 2008-11-16 13:02 ---
*** Bug 38155 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from jakub at gcc dot gnu dot org 2008-11-16 12:33 ---
Shorter testcase:
int foo (void *x)
{
int (*fn) (int);
*(void **)&fn = x;
return fn (6);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38140
--- Comment #15 from pault at gcc dot gnu dot org 2008-11-16 12:22 ---
(In reply to comment #14)
> (In reply to comment #13)
> > > I filled PR38119 for that PR.
> > This is probably stupid but what is the difference between the two PRs?
'twas stupid - I missed the difference between the
--- Comment #9 from steven at gcc dot gnu dot org 2008-11-16 12:17 ---
Advice to folks caring about compiler stability instead of supposedly faster:
Always use double-queue instead of overeager. The overeager solver is just not
reliable enough, and I have never found any proof for the s
--- Comment #4 from pault at gcc dot gnu dot org 2008-11-16 12:16 ---
Fixed on trunk. Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pault at gcc dot gnu dot org 2008-11-16 12:16 ---
HJ - I just fixed this on trunk, I believe. Note that I used the old PR in the
ChangeLog, for which apologies.
Thanks for the quick report. I would appreciate confirmation that this really
did the job.
Best regards
--- Comment #3 from pault at gcc dot gnu dot org 2008-11-16 12:13 ---
Subject: Bug 38119
Author: pault
Date: Sun Nov 16 12:11:53 2008
New Revision: 141915
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141915
Log:
2008-11-16 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #1 from razya at il dot ibm dot com 2008-11-16 12:12 ---
(In reply to comment #0)
> testsuite/gcc.dg/tree-ssa/update-unswitch-1.c is failing when compiled with
> -ftree-parallelize-loops=4
> In function âblaâ:
> /Develop/mainline_parallel/gcc/gcc/testsuite/gcc.dg/tree-ssa/up
testsuite/gcc.dg/tree-ssa/update-unswitch-1.c is failing when compiled with
-ftree-parallelize-loops=4
In function âblaâ:
/Develop/mainline_parallel/gcc/gcc/testsuite/gcc.dg/tree-ssa/update-unswitch-1.c:4:
internal compiler error: Segmentation fault
There are reduction patterns in this tescase, fo
--- Comment #7 from pault at gcc dot gnu dot org 2008-11-16 12:02 ---
Subject: Bug 37926
Author: pault
Date: Sun Nov 16 12:00:44 2008
New Revision: 141914
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141914
Log:
2008-11-16 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #1 from debian-gcc at lists dot debian dot org 2008-11-16
11:49 ---
not ada specific
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
--- Comment #4 from mikael at gcc dot gnu dot org 2008-11-16 11:38 ---
(In reply to comment #3)
> The problem appears to be the empty SOURCE with the presence of PAD.
I agree.
There are two bugs actually:
(1) the front-end doesn't expand the reshape.
(at least in this case: reshape
_insert':
/home/doko/gcc/snap/gcc-snapshot-20081116/build/gcc/../../src/gcc/tree.h:190:
relocation truncated to fit: R_PPC_REL24 against symbol `memmove@@GLIBC_2.0'
defined in .glink section in
/usr/lib/gcc/powerpc-linux-gnu/4.3.2/../../../../lib/crt1.o
c-lang.o: In function `VEC_tree_base_o
/Develop/mainline_parallel/gcc/gcc/testsuite/gcc.c-torture/execute/comp-goto-1.c
-w -O1 -lm -ftree-parallelize-loops=4
is failing at verify_flow_info
In function 'simulator_kernel':
/Develop/mainline_parallel/gcc/gcc/testsuite/gcc.c-torture/execute/comp-goto-1.c:57:
error: label
sim_base_addr has
--- Comment #2 from jan at jans-seite dot de 2008-11-16 10:17 ---
/proc/swaps:
FilenameTypeSizeUsed
Priority
/dev/sda1 partition 1052216 x -1
/usr/local/swap.filefile
when compiling :
/Develop/mainline_parallel/gcc/gcc/testsuite/gcc.c-torture/execute/comp-goto-1.c
-w -O1 -ftree-parallelize-loops=4
We get compiler error during verify_flow_info
comp-goto-1.c:57: error: label
sim_base_addr has incorrect context in bb 8
The context for sim_base_addr is the new ou
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-11-16 10:07
---
This should work now.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-11-16 10:06
---
Subject: Bug 38127
Author: ebotcazou
Date: Sun Nov 16 10:05:22 2008
New Revision: 141913
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141913
Log:
PR ada/38127
* gcc-interface/decl.c (mak
--- Comment #1 from domob at gcc dot gnu dot org 2008-11-16 09:27 ---
Daniel Kraft wrote:
> > I'm working out a test-case for PR 37779 and came across the following
> > program, which ICEs for today's trunk gfortran:
> >
> > SUBROUTINE test ()
> > IMPLICIT NONE
> > procptr => t
The following (possibly invalid) program ICEs:
MODULE m
IMPLICIT NONE
PROCEDURE(test), POINTER :: procptr
CONTAINS
SUBROUTINE test ()
IMPLICIT NONE
CALL bar (test)
procptr => test
END SUBROUTINE test
END MODULE m
The ICE is however not related to the missing RECURSIVE and
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-11-16 09:04 ---
Simplified test case (without the second reshape):
The problem appears to be the empty SOURCE with the presence of PAD.
$ cat bar.f90
program main
integer, parameter :: N = 3
integer :: A(N,N)
integer :: b(n+
--- Comment #1 from ktietz at gcc dot gnu dot org 2008-11-16 09:03 ---
This problem exists also for x86_64 based mingw.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--
85 matches
Mail list logo
